CVE-2026-59822: LiteLLM MCP auth bypass

Q: Is CVE-2026-59822 actively exploited?

No confirmed active exploitation of CVE-2026-59822 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-59822?

Upgrade LiteLLM to 1.84.0 or later immediately — the fix is a straightforward proxy-server update tracked in GHSA-7488-6r32-c95q and PR #26463. Until patched, audit whether the MCP Streamable HTTP endpoint is reachable from the public internet or untrusted network segments and restrict it (network ACLs, VPN, or reverse-proxy allowlisting) as a compensating control. Review whether OAuth2 passthrough is actually required for your MCP integration; disable it if not in active use. Post-patch, add detection for MCP requests associated with empty or malformed API key identities in LiteLLM's audit logs, and confirm no unauthorized MCP tool invocations occurred during the exposure window by reviewing historical logs back to when MCP support was enabled.

Q: What systems are affected by CVE-2026-59822?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI gateways / LLM proxies, MCP tool integrations.

Q: What is the CVSS score for CVE-2026-59822?

CVE-2026-59822 has a CVSS v3.1 base score of 8.2 (HIGH). The EPSS exploitation probability is 0.52%.

CISO Take

LiteLLM's proxy — the AI gateway many teams use to route calls to LLM APIs and MCP tools — had a logic flaw in its MCP Streamable HTTP endpoint: sending a fabricated Authorization header intentionally failed LiteLLM's own key validation, but instead of rejecting the request, that failure fell through to an OAuth2 passthrough path that returned an empty UserAPIKeyAuth() object, granting access to MCP tooling with no valid LiteLLM key at all. There's no CVSS score, no KEV listing, and EPSS sits at just 0.29% (top 80th percentile, i.e. low near-term exploitation likelihood), so this isn't being mass-exploited today — but any org exposing LiteLLM's MCP endpoint to untrusted callers is effectively running an unauthenticated gateway into whatever internal tools, data sources, or actions those MCP servers provide. Blast radius depends entirely on what's wired behind the proxy: internal APIs, file access, or agent actions could all become reachable without credentials. Patch to LiteLLM 1.84.0 now, and in the interim confirm the MCP Streamable HTTP endpoint isn't internet-facing and that OAuth2 passthrough isn't enabled unless strictly required. Audit LiteLLM access logs for MCP requests tied to anomalous or empty API key identities as a compensating detection.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Exploitability is currently low-effort in theory (no authentication needed, just a crafted Authorization header) but exploitation-in-the-wild signals are absent: no CVSS score has been assigned, EPSS is near-floor (0.29%), it's not in CISA KEV, and no public PoC or Nuclei template exists yet. That said, the vulnerability class — a fail-open fallback in an authentication path — is a classic, high-confidence bug once weaponized, and LiteLLM is widely deployed as an AI gateway in front of production LLM and MCP infrastructure. Real risk is asymmetric: low probability of opportunistic mass exploitation right now, but high potential impact for any organization that has exposed the MCP Streamable HTTP endpoint externally or to semi-trusted networks. Treat this as a 'patch on the next maintenance window, verify exposure today' issue rather than a fire drill.

How does the attack unfold?

Initial Access

Unauthenticated attacker sends a request to LiteLLM's MCP Streamable HTTP endpoint with a fabricated Authorization header.

AML.T0049

Authentication Bypass

The fabricated header fails LiteLLM's key validation but triggers the OAuth2 passthrough fallback, which returns an empty UserAPIKeyAuth() object instead of denying access.

Tool Access

The attacker interacts with MCP tools proxied through LiteLLM without ever presenting a valid LiteLLM API key.

AML.T0053

Impact

Depending on what is wired behind the MCP servers, the attacker can read data, call internal APIs, or trigger downstream actions with no authorization enforced.

AML.T0086

Initial Access

Unauthenticated attacker sends a request to LiteLLM's MCP Streamable HTTP endpoint with a fabricated Authorization header.

AML.T0049

Authentication Bypass

The fabricated header fails LiteLLM's key validation but triggers the OAuth2 passthrough fallback, which returns an empty UserAPIKeyAuth() object instead of denying access.

Tool Access

The attacker interacts with MCP tools proxied through LiteLLM without ever presenting a valid LiteLLM API key.

AML.T0053

Impact

Depending on what is wired behind the MCP servers, the attacker can read data, call internal APIs, or trigger downstream actions with no authorization enforced.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	< 1.84.0	`1.84.0`
57.0K OpenSSF 5.8 6 dependents Pushed 3d ago 49% patched ~47d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

8.2 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 42% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I Low

A None

What should I do?

1 step

Upgrade LiteLLM to 1.84.0 or later immediately — the fix is a straightforward proxy-server update tracked in GHSA-7488-6r32-c95q and PR #26463. Until patched, audit whether the MCP Streamable HTTP endpoint is reachable from the public internet or untrusted network segments and restrict it (network ACLs, VPN, or reverse-proxy allowlisting) as a compensating control. Review whether OAuth2 passthrough is actually required for your MCP integration; disable it if not in active use. Post-patch, add detection for MCP requests associated with empty or malformed API key identities in LiteLLM's audit logs, and confirm no unauthorized MCP tool invocations occurred during the exposure window by reviewing historical logs back to when MCP support was enabled.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

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

How is it classified?

Auth Bypass API Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2 - AI system operation and monitoring

NIST AI RMF

MANAGE-2.3 - Mechanisms are in place to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-59822?

LiteLLM's proxy — the AI gateway many teams use to route calls to LLM APIs and MCP tools — had a logic flaw in its MCP Streamable HTTP endpoint: sending a fabricated Authorization header intentionally failed LiteLLM's own key validation, but instead of rejecting the request, that failure fell through to an OAuth2 passthrough path that returned an empty UserAPIKeyAuth() object, granting access to MCP tooling with no valid LiteLLM key at all. There's no CVSS score, no KEV listing, and EPSS sits at just 0.29% (top 80th percentile, i.e. low near-term exploitation likelihood), so this isn't being mass-exploited today — but any org exposing LiteLLM's MCP endpoint to untrusted callers is effectively running an unauthenticated gateway into whatever internal tools, data sources, or actions those MCP servers provide. Blast radius depends entirely on what's wired behind the proxy: internal APIs, file access, or agent actions could all become reachable without credentials. Patch to LiteLLM 1.84.0 now, and in the interim confirm the MCP Streamable HTTP endpoint isn't internet-facing and that OAuth2 passthrough isn't enabled unless strictly required. Audit LiteLLM access logs for MCP requests tied to anomalous or empty API key identities as a compensating detection.

Is CVE-2026-59822 actively exploited?

No confirmed active exploitation of CVE-2026-59822 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59822?

Upgrade LiteLLM to 1.84.0 or later immediately — the fix is a straightforward proxy-server update tracked in GHSA-7488-6r32-c95q and PR #26463. Until patched, audit whether the MCP Streamable HTTP endpoint is reachable from the public internet or untrusted network segments and restrict it (network ACLs, VPN, or reverse-proxy allowlisting) as a compensating control. Review whether OAuth2 passthrough is actually required for your MCP integration; disable it if not in active use. Post-patch, add detection for MCP requests associated with empty or malformed API key identities in LiteLLM's audit logs, and confirm no unauthorized MCP tool invocations occurred during the exposure window by reviewing historical logs back to when MCP support was enabled.

What systems are affected by CVE-2026-59822?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI gateways / LLM proxies, MCP tool integrations.

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

CVE-2026-59822 has a CVSS v3.1 base score of 8.2 (HIGH). The EPSS exploitation probability is 0.52%.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI gateways / LLM proxiesMCP tool integrations

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization header to trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object, allowing requests to reach MCP tooling without a valid LiteLLM key. This issue is fixed in version 1.84.0.

Exploitation Scenario

An unauthenticated attacker identifies a LiteLLM proxy instance with the MCP Streamable HTTP endpoint exposed (e.g., via network scanning or discovery of the org's AI infrastructure). They send a request with a deliberately malformed or fabricated Authorization header — one crafted specifically to fail LiteLLM's native key validation. Instead of a clean rejection, the failure triggers the OAuth2 passthrough fallback path, which constructs an empty UserAPIKeyAuth() object and treats the request as authorized. The attacker now invokes whatever MCP tools are connected to that LiteLLM instance — potentially reading internal data, calling internal APIs, or triggering downstream actions — without ever presenting a valid LiteLLM key or credential.

Weaknesses (CWE)

CWE-287 Improper Authentication Primary CWE-287 Improper Authentication Primary CWE-306 Missing Authentication for Critical Function Primary CWE-287 Improper Authentication CWE-306 Missing Authentication for Critical Function

CWE-287 — Improper Authentication: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.