CVE-2026-108547 in Astron RPA
Summary
by MITRE • 10/10/2026
AstronRPA through 1.1.6 contains a missing tenant authorization check in robot-service that allows authenticated users to read other tenants' shared variables via the get-batch-shared-var endpoint. Attackers can enumerate sequential shared variable IDs and decrypt all-users variables re-encrypted with their own tenant key to recover other tenants' credentials in plaintext.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in AstronRPA versions through 1.1.6 represents a critical failure in multi-tenant isolation, specifically manifesting as an insecure direct object reference within the robot-service component. This flaw stems from a missing tenant authorization check on the get-batch-shared-var endpoint, which is designed to retrieve shared variables for robotic process automation workflows. In a properly secured multi-tenant architecture, every request accessing data must be rigorously validated against the requesting user's specific tenant identifier to ensure that resources are only accessible to authorized entities within that logical boundary. The absence of this validation allows any authenticated user to interact with the endpoint without restriction based on their assigned tenant context, effectively bypassing the fundamental security control intended to segregate customer data.
The operational impact of this vulnerability is severe due to the specific mechanism by which shared variables are stored and encrypted. AstronRPA employs a scheme where all-users variables are re-encrypted using the individual tenant's key before being served or processed. While encryption provides confidentiality, it relies heavily on proper access controls to prevent unauthorized decryption attempts. Because the endpoint lacks tenant validation, an attacker can exploit this by enumerating sequential shared variable identifiers. By systematically requesting these IDs, the attacker triggers the system to decrypt and return data associated with other tenants using their own valid tenant key. This process effectively neutralizes the encryption protection for cross-tenant access, as the system blindly processes requests regardless of whether the requested resource belongs to the requester's organization or a different one.
Consequently, this flaw enables the complete compromise of sensitive credentials stored within shared variables across all tenants in the platform. Attackers can recover plaintext passwords, API keys, and other authentication secrets belonging to unrelated organizations by simply iterating through variable IDs and capturing the decrypted output. This scenario constitutes a classic case of broken access control where logical flaws override cryptographic safeguards. The ability to enumerate sequential identifiers further exacerbates the risk, as it allows for automated scanning tools to rapidly harvest large volumes of sensitive data without requiring complex reverse engineering or exploitation techniques beyond basic HTTP request manipulation.
From a standards perspective, this vulnerability aligns with CWE-639, which describes issues related to authorization bypass via direct object references, and falls under MITRE ATT&CK technique T1078, specifically referencing valid accounts used for lateral movement or data exfiltration in cloud environments. The lack of proper tenant isolation also touches upon principles outlined in OWASP API Security Top 10, particularly those concerning broken object level authorization where APIs fail to enforce sufficient access controls on resource identifiers. To mitigate this risk, the vendor must implement strict server-side validation that binds every request for shared variables to a verified tenant ID associated with the authenticated user's session. Additionally, implementing randomization of variable IDs rather than sequential integers can reduce the efficiency of enumeration attacks, although it does not replace the need for robust authorization checks. Immediate patching to version 1.1.7 or later is required to resolve this critical security deficiency and restore multi-tenant data isolation integrity.