CVE-2026-85178: IDOR leaks cross-tenant LLM provider

CISO Take

Helicone's vault key retrieval endpoint fails to verify that the requesting organization owns the vault key it's fetching, letting any admin or owner user in one tenant pull decrypted OpenAI, Anthropic, or Bedrock API keys belonging to other customers. This is a textbook IDOR (CWE-639) with network access, low privileges, low complexity, and no user interaction — CVSS 7.7 with a scope-changed confidentiality impact, meaning a compromise in one tenant's account directly exposes secrets outside its trust boundary. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so opportunistic mass exploitation isn't currently observed, but the flaw requires nothing beyond a valid low-privilege account and a guessable or enumerable providerKeyId — trivial for any existing Helicone customer to attempt. Any org running Helicone as an LLM observability/gateway layer should patch immediately (fix committed at ca34549), rotate all provider API keys proxied through Helicone as a precaution, and audit access logs for anomalous GET requests to /v1/vault/key/{id} referencing keys outside the requester's organization. Until patched, treat any provider key stored in Helicone's vault as potentially exposed to other tenants.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

High risk despite low CVSS-adjacent complexity barriers: PR:L and no UI make this exploitable by any authenticated low-privilege admin/owner account, and the missing organization-scope check is a classic multi-tenant authorization gap. Impact is confined to confidentiality (C:H, I:N, A:N) but the object exposed — plaintext upstream LLM provider credentials — is maximally sensitive since possession enables full impersonation of the victim's AI usage and billing. No active exploitation or scanner coverage lowers immediate urgency, but the low bar to exploit (any tenant admin, sequential/enumerable IDs) means real-world abuse in a multi-tenant SaaS is plausible without any tooling.

How does the attack unfold?

Initial Access

Attacker obtains admin or owner privileges within their own (legitimate or free-tier) Helicone organization.

AML.T0012

Exploitation

Attacker calls GET /v1/vault/key/{providerKeyId} with a providerKeyId belonging to another tenant; the endpoint fails to validate organization ownership and returns the decrypted key.

AML.T0055

Impact

Attacker uses the stolen plaintext OpenAI/Anthropic/Bedrock key to run unauthorized inference, exfiltrate data, or pivot into the victim's cloud environment.

AML.T0025

Initial Access

Attacker obtains admin or owner privileges within their own (legitimate or free-tier) Helicone organization.

AML.T0012

Exploitation

Attacker calls GET /v1/vault/key/{providerKeyId} with a providerKeyId belonging to another tenant; the endpoint fails to validate organization ownership and returns the decrypted key.

AML.T0055

Impact

Attacker uses the stolen plaintext OpenAI/Anthropic/Bedrock key to run unauthorized inference, exfiltrate data, or pivot into the victim's cloud environment.

AML.T0025

How severe is it?

CVSS 3.1

7.7 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SChanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade to the patched Helicone version containing commit ca34549ea56f7ed587843f82d9cc19baa1f36ba4, which adds organization-ownership validation to VaultManager.getDecryptedProviderKeyById(). 2) Rotate all provider API keys (OpenAI, Anthropic, Bedrock) stored in Helicone's vault as a precaution, since past exposure cannot be ruled out. 3) Review access logs/audit trails for GET /v1/vault/key/{providerKeyId} requests where the providerKeyId does not belong to the requesting organization. 4) If self-hosting Helicone, restrict admin/owner role assignment and consider temporarily disabling the vault key retrieval endpoint until patched. 5) For SaaS-hosted Helicone customers, confirm with the vendor that the fix has been deployed platform-wide.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassData LeakageAPIAML.T0012- Valid Accounts AML.T0025- Exfiltration via Cyber Means AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.8.2-AI system data and access security

NIST AI RMF

MANAGE-1.1-AI system risks are managed relative to organizational risk tolerance

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-85178?

Helicone's vault key retrieval endpoint fails to verify that the requesting organization owns the vault key it's fetching, letting any admin or owner user in one tenant pull decrypted OpenAI, Anthropic, or Bedrock API keys belonging to other customers. This is a textbook IDOR (CWE-639) with network access, low privileges, low complexity, and no user interaction — CVSS 7.7 with a scope-changed confidentiality impact, meaning a compromise in one tenant's account directly exposes secrets outside its trust boundary. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so opportunistic mass exploitation isn't currently observed, but the flaw requires nothing beyond a valid low-privilege account and a guessable or enumerable providerKeyId — trivial for any existing Helicone customer to attempt. Any org running Helicone as an LLM observability/gateway layer should patch immediately (fix committed at ca34549), rotate all provider API keys proxied through Helicone as a precaution, and audit access logs for anomalous GET requests to /v1/vault/key/{id} referencing keys outside the requester's organization. Until patched, treat any provider key stored in Helicone's vault as potentially exposed to other tenants.

Is CVE-2026-85178 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85178, increasing the risk of exploitation.

How to fix CVE-2026-85178?

1) Upgrade to the patched Helicone version containing commit ca34549ea56f7ed587843f82d9cc19baa1f36ba4, which adds organization-ownership validation to VaultManager.getDecryptedProviderKeyById(). 2) Rotate all provider API keys (OpenAI, Anthropic, Bedrock) stored in Helicone's vault as a precaution, since past exposure cannot be ruled out. 3) Review access logs/audit trails for GET /v1/vault/key/{providerKeyId} requests where the providerKeyId does not belong to the requesting organization. 4) If self-hosting Helicone, restrict admin/owner role assignment and consider temporarily disabling the vault key retrieval endpoint until patched. 5) For SaaS-hosted Helicone customers, confirm with the vendor that the fix has been deployed platform-wide.

What systems are affected by CVE-2026-85178?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways / observability proxies, agent frameworks, model serving.

What is the CVSS score for CVE-2026-85178?

CVE-2026-85178 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.41%.

What is the AI security impact?

Affected AI Architectures

LLM API gateways / observability proxiesagent frameworksmodel serving

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0025Exfiltration via Cyber Means

AML.T0055Unsecured Credentials

Compliance Controls Affected

ISO 42001: A.8.2

NIST AI RMF: MANAGE-1.1

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker who has admin or owner privileges in their own (possibly free-tier or trial) Helicone organization enumerates or guesses providerKeyId values — which may be sequential or predictable UUIDs — and issues GET requests to /v1/vault/key/{providerKeyId}. Because the endpoint never checks that the key belongs to the caller's organization, the attacker receives the decrypted plaintext OpenAI/Anthropic/Bedrock API key of an unrelated victim tenant. The attacker then uses that key directly against the provider's API to run inference at the victim's expense, exfiltrate any data accessible via that key's scope, or use a leaked Bedrock credential to attempt lateral movement into the victim's AWS environment.

Weaknesses (CWE)

CWE-639Authorization Bypass Through User-Controlled KeyPrimary CWE-639Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.