CVE-2026-85178 in Helicone
Summary
by MITRE • 09/03/2026
Helicone's VaultManager.getDecryptedProviderKeyById() function in the GET /v1/vault/key/{providerKeyId} endpoint fails to validate the requester's organization against the vault key's organization identifier. Attackers with admin or owner privileges in any organization can retrieve decrypted upstream provider credentials for other tenants, including plaintext OpenAI, Anthropic, and Bedrock API keys.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified within Helicone’s VaultManager.getDecryptedProviderKeyById() function represents a critical failure in access control logic, specifically categorized under CWE-284 Improper Access Control. This flaw exists within the GET /v1/vault/key/{providerKeyId} endpoint and stems from an insufficient validation of the requester's organizational context against the target resource’s associated organization identifier. In secure multi-tenant architectures, it is imperative that access to sensitive resources such as encrypted credentials be strictly scoped to the owning tenant or authorized administrators thereof. However, in this instance, the system fails to enforce these boundaries, allowing a significant breach of data isolation between tenants.
The technical nature of this flaw allows attackers possessing administrative or owner privileges within any single organization to bypass security controls and retrieve decrypted upstream provider keys belonging to other distinct organizations. By manipulating the request parameters to target specific vault key identifiers, an authenticated user can extract plaintext API credentials for major cloud service providers including OpenAI, Anthropic, and AWS Bedrock. This capability effectively neutralizes the intended separation of duties and data privacy guarantees provided by the platform’s multi-tenancy model. The absence of a check ensuring that the requesting entity belongs to the same organization as the vault key constitutes a classic Insecure Direct Object Reference scenario where object-level permissions are not properly enforced server-side.
The operational impact of this vulnerability is severe, potentially leading to unauthorized access to external AI services and subsequent financial fraud or data exfiltration on behalf of other tenants. Since API keys for providers like OpenAI often carry billing responsibilities, compromised credentials could be used by malicious actors to incur substantial costs against the victim organizations' accounts. Furthermore, if these provider APIs have been configured with broader permissions than necessary, attackers might gain access to sensitive customer data processed through those services. This breach undermines trust in the platform’s security posture and exposes all tenants on the infrastructure to risk based solely on the compromise of a single tenant's administrative credentials.
To mitigate this vulnerability, immediate remediation should focus on implementing strict authorization checks within the VaultManager.getDecryptedProviderKeyById() method. The system must verify that the organization ID associated with the authenticated user matches the organization ID linked to the requested vault key before proceeding with decryption and retrieval operations. If a mismatch is detected, the request should be denied with an appropriate access forbidden response rather than returning data or raising ambiguous errors. Additionally, adopting principles of least privilege ensures that even administrative roles are restricted from accessing resources outside their designated organizational boundary unless explicitly authorized through cross-tenant delegation mechanisms which require explicit consent and logging. Regular security audits and penetration testing focused on multi-tenancy isolation will help identify similar logical flaws in other endpoints across the application ecosystem.