Astron Rpa
Monthly
AstronRPA through 1.1.6 exposes other tenants' credential-bearing shared variables to any authenticated low-privilege user, because robot-service's get-batch-shared-var endpoint applies no tenant authorization check to caller-supplied shared-variable IDs. An attacker can enumerate sequential IDs, request them in batch, and since the service re-encrypts all-users variables with the caller's own tenant key, the returned ciphertext decrypts to plaintext secrets belonging to other tenants. The provider-assigned CVSS 4.0 score is 7.1, our assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only), exploitation requires a valid account on a multi-tenant deployment, no public exploit identified at time of analysis, and no CISA KEV entry or EPSS data was provided.
Remote code execution on the AstronRPA desktop client through version 1.1.6 is achievable by an on-path attacker who intercepts the client's plaintext HTTP auto-update check and serves a malicious update manifest with an unsigned NSIS installer, which electron-updater installs without verifying a publisher signature. The weakness is CWE-494 (download of code without integrity check), rated 7.7 under CVSS 4.0 with High attack complexity and attack requirements Present because the attacker must already hold a man-in-the-middle position and the client must run an update check; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis, so this is a conditional, non-scalable threat rather than a mass-exploitation emergency.
Remote code execution in AstronRPA through 1.1.6 is possible when the desktop client's smart-component chat processes attacker-controlled content and renders unsanitized LLM output through v-html, allowing HTML event handlers to call an unrestricted open-path IPC handler with shell metacharacters and run OS commands as the desktop user. The issue is remote and unauthenticated per the CVSS 4.0 vector (PR:N), but practical exploitation requires user interaction (UI:P), depends on reliably coercing non-deterministic LLM output (AC:H/AT:P), and is limited to the logged-in user's privileges. The CVSS 4.0 base score is 7.7 (High) with VC:H/VI:H/VA:H; no public exploit or CISA KEV active exploitation is identified in the provided data.
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.
AstronRPA through 1.1.6 exposes other tenants' credential-bearing shared variables to any authenticated low-privilege user, because robot-service's get-batch-shared-var endpoint applies no tenant authorization check to caller-supplied shared-variable IDs. An attacker can enumerate sequential IDs, request them in batch, and since the service re-encrypts all-users variables with the caller's own tenant key, the returned ciphertext decrypts to plaintext secrets belonging to other tenants. The provider-assigned CVSS 4.0 score is 7.1, our assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (confidentiality only), exploitation requires a valid account on a multi-tenant deployment, no public exploit identified at time of analysis, and no CISA KEV entry or EPSS data was provided.
Remote code execution on the AstronRPA desktop client through version 1.1.6 is achievable by an on-path attacker who intercepts the client's plaintext HTTP auto-update check and serves a malicious update manifest with an unsigned NSIS installer, which electron-updater installs without verifying a publisher signature. The weakness is CWE-494 (download of code without integrity check), rated 7.7 under CVSS 4.0 with High attack complexity and attack requirements Present because the attacker must already hold a man-in-the-middle position and the client must run an update check; there is no public exploit identified at time of analysis and no vendor-released patch identified at time of analysis, so this is a conditional, non-scalable threat rather than a mass-exploitation emergency.
Remote code execution in AstronRPA through 1.1.6 is possible when the desktop client's smart-component chat processes attacker-controlled content and renders unsanitized LLM output through v-html, allowing HTML event handlers to call an unrestricted open-path IPC handler with shell metacharacters and run OS commands as the desktop user. The issue is remote and unauthenticated per the CVSS 4.0 vector (PR:N), but practical exploitation requires user interaction (UI:P), depends on reliably coercing non-deterministic LLM output (AC:H/AT:P), and is limited to the logged-in user's privileges. The CVSS 4.0 base score is 7.7 (High) with VC:H/VI:H/VA:H; no public exploit or CISA KEV active exploitation is identified in the provided data.
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.