Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach OpenResty gateway over network
-
DeliverySend arbitrary Bearer token header
-
ExploitBypass auth_handler.lua validation
-
ExecutionSpoof X-User-Id/user_id header
-
ImpactAccess protected API routes as any user
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | The target must run the AstronRPA OpenResty/nginx gateway (as shipped in the project's docker nginx/lua configuration) with the vulnerable auth_handler.lua, and the attacker must have network access to that gateway and to the /api/resource/ or /api/rpa-ai-service/ routes. No special non-default configuration, credentials, or user interaction is required - the flaw is present in the default auth logic that validates no Bearer token. The practical limiting factor is network exposure: impact is confined to users who deploy the gateway reachable by the attacker (e.g. internet-exposed or attacker-accessible internal network), and scored impact is limited to those two API route families rather than full system compromise. |
| Impact | This is a genuine but moderate-severity authentication bypass. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network-reachable, low-complexity, unauthenticated exploitation requiring no user interaction - the worst-case exploitability profile - yet the base score is only 6.9 (Medium) because impact is capped at VC:L/VI:L/VA:L with no subsequent-system impact (SC:N/SI:N/SA:N). The description fully corroborates the vector: the OpenResty gateway's auth_handler.lua accepts ANY Bearer token, so no privileges are required (PR:N is accurate). No EPSS score, CISA KEV listing, or public POC flag was supplied, so there is no evidence of active or at-scale exploitation; the signals are therefore not conflicting - they consistently point to an easily-triggered flaw of limited blast radius. The limited impact rating is the main thing keeping this below High: an attacker can reach and act within /api/resource/ and /api/rpa-ai-service/ and impersonate arbitrary users, but the scored impact is Low across confidentiality/integrity/availability. Caveat: user-impersonation (spoofing X-User-Id/user_id to 'act as any user') could in some deployments yield higher integrity/confidentiality impact than VC:L/VI:L reflects - verify actual data exposure on those routes against your deployment before de-prioritizing. |
| Exploit ScenarioDerived | An attacker with network reachability to the AstronRPA OpenResty gateway sends an HTTP request to /api/resource/ or /api/rpa-ai-service/ carrying an arbitrary 'Authorization: Bearer <anything>' header, which auth_handler.lua accepts without validation. The attacker then adds a spoofed X-User-Id or user_id header to impersonate any chosen user and act with that identity. No public exploit identified at time of analysis, but the flaw requires no authentication and only a crafted header, making it trivially reproducible. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 10, 2026
Authentication bypass in iFlytek AstronRPA through 1.1.6 allows unauthenticated, network-positioned attackers to reach the /api/resource/ and /api/rpa-ai-service/ API route families by presenting an arbitrary Bearer token, because the OpenResty gateway's auth_handler.lua accepts any value without validating it. Beyond simply getting past the gate, an attacker can spoof the X-User-Id or user_id header to impersonate any user of the platform, yielding low-level read and write access to those API routes. There is no public exploit identified at time of analysis, the issue is not confirmed actively exploited (no CISA KEV listing), and no vendor-released patch has been identified at time of analysis; the practical impact ceiling is the two affected route families on a gateway reachable by the attacker, not full system compromise.
RemediationAI
No vendor-released patch has been identified at time of analysis, so the primary action is to track the upstream repository and its issue tracker (https://github.com/iflytek/astron-rpa and https://github.com/iflytek/astron-rpa/issues/886) and upgrade to a release after 1.1.6 as soon as one is published and independently confirmed to correct the handler. Until then, fix the two code paths directly: in the OpenResty gateway modify auth_handler.lua so the Bearer token is cryptographically validated (signature, issuer, audience and expiry) instead of being accepted as an opaque string, and in backend/ai-service/app/dependencies/__init__.py stop deriving caller identity from the client-controlled X-User-Id / user_id headers, taking it only from the verified token claim - the trade-off is that any internal automation or RPA connectors currently relying on header-based impersonation will need to obtain real tokens. As compensating controls, do not expose the OpenResty/nginx gateway to untrusted networks: restrict it with firewall rules or a VPN to known client ranges, which blocks remote RPA workers and dashboards that terminate outside those ranges, and place an authenticating reverse proxy or API gateway in front of AstronRPA that validates tokens before traffic reaches auth_handler.lua, accepting the operational overhead of duplicated authentication configuration. Additionally, disable or block the /api/rpa-ai-service/ route where it is not strictly required, reducing the reachable surface, and alert on access logs showing placeholder or malformed Bearer values or X-User-Id headers that do not match the authenticated principal, since those patterns reliably indicate exploitation attempts. Consult the VulnCheck advisory (https://www.vulncheck.com/advisories/astronrpa-through-1.1.6-authentication-bypass-via-arbitrary-bearer-token) and the upstream issue for definitive fix guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
AstronRPA ships an OpenResty/nginx reverse-proxy tier whose Lua access handler (docker/volumes/nginx/lua/auth_handler.lua, lines 21-35 in v1.1.6) is supposed to authenticate inbound API calls before proxying them to the Python backend. The handler's logic accepts any Bearer token without performing signature, expiry, audience or issuer validation, which is a classic improper authentication condition (CWE-287): the authentication check exists structurally but does not establish any binding between the presented credential and a real identity. The bypass is compounded at the backend layer, where the ai-service dependency module (backend/ai-service/app/dependencies/__init__.py, lines 10-24) derives the caller's identity from client-supplied X-User-Id / user_id headers rather than from a verified token claim, so trust is propagated from an unvalidated header straight into request context. The affected attack surface is the /api/resource/ and /api/rpa-ai-service/ route families exposed by the gateway; the CPE cpe:2.3:a:iflytek:astron-rpa:*:*:*:*:*:*:*:* indicates the vendor product is the tracked component, with 1.1.6 documented as the last affected build. The vendor/CNA CVSS v4.0 base score is 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N, low confidentiality/integrity/availability impact), and our independent assessment aligns as a CVSS v3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L: remote, pre-authentication, no user interaction, with limited rather than systemic impact confined to the two exposed API route families.
Know when Astron Rpa gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Unvalidated Bearer token makes exploitation network, low-complexity and unauthenticated (PR:N/AC:L), while impact stays Low and scope unchanged as access is limited to specific API routes with user impersonation.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
AstronRPA through 1.1.6 contains an authentication bypass vulnerability in the OpenResty gateway's auth_handler.lua that accepts any Bearer token without validation. Unauthenticated attackers can send arbitrary Bearer values to reach /api/resource/ and /api/rpa-ai-service/ routes and spoof X-User-Id or user_id headers to act as any user.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Astron Rpa
View allRemote code execution in AstronRPA through 1.1.6 is possible when the desktop client's smart-component chat processes at
Remote code execution on the AstronRPA desktop client through version 1.1.6 is achievable by an on-path attacker who int
AstronRPA through 1.1.6 exposes other tenants' credential-bearing shared variables to any authenticated low-privilege us
EUVD-2026-96343
GHSA-fh8f-pxvw-9f29
NVD
CVE.org
EPSS
Exploit-DB