Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-10T15:16:57.707Z",
  "pubdate": "2026-10-10T15:16:57.707Z",
  "executiveSummary": "AstronRPA versions through 1.1.6 are affected by an Improper Authorization vulnerability located within the robot-service component.\nThe flaw stems from a missing tenant-level validation check on the get-batch-shared-var endpoint, which facilitates unauthorized cross-tenant data access.\nAn authenticated user can exploit this vulnerability to perform unauthorized reads of sensitive variables assigned to other tenants.\nThe risk is severe, as the vulnerability allows for the enumeration of shared variable IDs and the subsequent decryption of data using the attacker's own tenant key, potentially exposing plaintext credentials and sensitive configuration data.\nThe vulnerability is exploitable by any authenticated user within the system, requiring no escalated administrative privileges, and poses a significant risk to multi-tenant isolation and data confidentiality.",
  "technicalDetails": "The vulnerability exists in the robot-service of AstronRPA, specifically within the API implementation of the get-batch-shared-var endpoint. The root cause is a failure to implement robust server-side tenant authorization checks before processing requests for shared variables. In a multi-tenant environment, the system is expected to validate that the requested resource ID strictly belongs to the authenticated user's tenant context.\nExploitation follows a systematic process starting with authenticated access to the target instance. Because the get-batch-shared-var endpoint lacks tenant isolation, an attacker can supply sequential integer IDs representing shared variables across the platform. By iterating through these IDs, the attacker captures variable data that is cryptographically tied to other tenants.\nThe system's cryptographic implementation further exacerbates the vulnerability. While shared variables are encrypted, the system re-encrypts these values using the attacker's own tenant key upon retrieval if not properly governed by access controls. This allows an attacker to decrypt the intercepted payload using their own authorized key, effectively recovering the plaintext contents of the variables.\nThe attack flow is summarized as follows: 1) The attacker authenticates to the platform using legitimate credentials. 2) The attacker identifies the get-batch-shared-var endpoint within the robot-service. 3) The attacker initiates a brute-force or enumeration attack against the shared variable ID parameter. 4) The service returns serialized variable objects belonging to other tenants. 5) The attacker utilizes the tenant-specific encryption key infrastructure to decrypt the retrieved sensitive information. 6) The attacker successfully recovers credentials or other plain-text sensitive data associated with other tenants.\nThe vulnerable component is the robot-service, which handles inter-service communication and variable persistence management. Given that the API is exposed to authenticated users, the attack surface is significant for any organization utilizing the platform in a multi-tenant configuration. The impact is a total breakdown of data isolation, enabling full-scale exfiltration of sensitive environment variables, credentials, and automation secrets stored within the shared variable repository."
}