Description

Rainbond through 6.9.7 contains a broken access control vulnerability in the CheckToken function that allows authenticated attackers to access unauthorized enterprise resources by substituting another enterprise's tenant name in URL paths. Attackers can use any valid API token to bypass enterprise ID verification and access or modify another enterprise's services, plugins, environment variables, and certificates.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-13T18:18:16.670Z",
  "pubdate": "2026-08-13T18:18:16.670Z",
  "executiveSummary": "Rainbond through 6.9.7 suffers from a broken access control vulnerability residing within the CheckToken function, which undermines the multi-tenant security isolation boundaries of the platform.\nThe vulnerability allows authenticated attackers to perform unauthorized cross-tenant operations by manipulating URL paths to substitute arbitrary enterprise tenant names.\nBy leveraging any valid API token, an adversary can completely bypass enterprise ID verification mechanisms, leading to severe unauthorized data access and modification capabilities across distinct enterprise resources.\nThe operational impact encompasses the compromise of sensitive enterprise assets, including managed services, plugins, environment variables, and cryptographic certificates.\nThe risk implication is critical, as any compromised or legitimately obtained low-privilege API token can be weaponized to horizontally escalate privileges across disparate enterprise environments hosted on the same Rainbond instance.\nExploitation requires authenticated access to the application via valid API credentials, alongside the ability to craft or modify HTTP requests targeting enterprise-specific URL paths.",
  "technicalDetails": "The root cause of the vulnerability stems from improper authorization enforcement within the CheckToken function in Rainbond through 6.9.7.\nSpecifically, the application fails to adequately validate whether the authenticated user or the provided API token holds authorization to access resources associated with the specific enterprise tenant identifier specified in the incoming HTTP request path.\nThe vulnerable component involves the API routing and access control validation logic centered around the CheckToken function, which processes API requests across multi-tenant boundaries.\nAuthentication and privilege requirements are minimal; an attacker only needs a valid API token from any enterprise within the Rainbond deployment to initiate exploitation.\nThe attack flow proceeds as follows: First, an attacker obtains a valid API token through legitimate authentication or prior compromise within their own authorized enterprise context.\nNext, the attacker crafts an HTTP API request targeting a sensitive resource belonging to a different victim enterprise. In the URL path, the attacker replaces their own enterprise tenant name or identifier with the target victim's enterprise tenant name.\nWhen the request hits the Rainbond application, the CheckToken function authenticates the provided API token successfully but fails to enforce tenant-isolation checks against the enterprise identifier embedded in the URL path.\nConsequently, the application treats the request as authorized within the context of the substituted victim enterprise.\nThis allows the attacker to execute unauthorized read, write, or administrative operations against the victim's enterprise resources.\nPost-exploitation impact includes full operational access to the victim enterprise's services, custom plugins, sensitive environment variables, and security certificates, potentially enabling lateral movement, data exfiltration, or service disruption across the entire Rainbond cluster."
}