CVE-2026-59822: LiteLLM MCP Authentication Bypass Added to CISA KEV — Patch to 1.84.0

TL;DR

CVE-2026-59822 is an improper authentication vulnerability in BerriAI's LiteLLM that lets an unauthenticated attacker establish an authenticated MCP session using an arbitrary Bearer token. Any organization running a LiteLLM gateway below version 1.84.0 with the MCP Streamable HTTP endpoint exposed is affected. CISA added the flaw to the Known Exploited Vulnerabilities catalog on 2026-09-02 with a remediation due date of 2026-09-16 — patch to 1.84.0 or isolate the MCP endpoint today.

What is this vulnerability?

Field	Detail
CVE	CVE-2026-59822
Vendor / Product	BerriAI / LiteLLM
Vulnerability name	BerriAI LiteLLM Improper Authentication Vulnerability
Weakness	CWE-287 (Improper Authentication), CWE-306 (Missing Authentication for Critical Function)
Affected versions	All LiteLLM releases prior to 1.84.0
Fixed version	LiteLLM 1.84.0
CISA KEV added	2026-09-02
CISA KEV due date	2026-09-16
Known ransomware use	Unknown
CVSS v3.1 (NVD)	8.2 HIGH — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
CVSS v4.0 (GitHub)	8.8 HIGH — AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
EPSS	0.0087 (~57th percentile)

Overview

CVE-2026-59822 is an authentication bypass in LiteLLM, an AI gateway and proxy server that fronts LLM APIs in OpenAI-compatible or native formats. The flaw lives in the MCP (Model Context Protocol) Streamable HTTP endpoint. Prior to version 1.84.0, a request carrying a fabricated Authorization header could trigger an OAuth2 passthrough fallback path that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object. That empty object satisfied downstream authorization checks, so the request proceeded to MCP tooling as though it had been authenticated. The issue was publicly disclosed on 2026-09-02 and fixed in LiteLLM 1.84.0.

Every LiteLLM release before 1.84.0 is affected. The severity picture is consistent across sources: NVD rates the issue 8.2 (HIGH) under CVSS 3.1, while GitHub's advisory assigns 8.8 (HIGH) under CVSS 4.0. Both agree that confidentiality impact is high and integrity impact is low, with no privileges or user interaction required. The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N describes a remotely reachable, low-complexity, unauthenticated issue — the profile of a flaw that is straightforward to exploit once an attacker finds a reachable endpoint.

Defenders should care for three reasons. First, CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on 2026-09-02, which means exploitation should be treated as observed rather than theoretical. Second, LiteLLM commonly sits in a privileged position: it holds upstream provider credentials and mediates access to internal tooling, so the blast radius extends well beyond the gateway itself. Third, a public proof-of-concept repository has appeared on GitHub, lowering the barrier for opportunistic exploitation. The remediation deadline of 2026-09-16 applies to federal and regulated environments, but the operational logic applies to everyone running an exposed gateway.

Technical details

Root cause. The MCP Streamable HTTP handler in LiteLLM prior to 1.84.0 performed key validation in a way that could be short-circuited by an OAuth2 passthrough fallback path. When a request arrived with an Authorization header that failed LiteLLM key validation, the code could fall through to the passthrough branch and replace the failed validation result with an empty UserAPIKeyAuth() object. That empty object satisfied downstream authorization checks, so the request reached MCP tooling as if it had been authenticated. This maps to CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function).

Vulnerable component. The MCP Streamable HTTP endpoint — the interface through which MCP clients and tooling communicate with the LiteLLM gateway. The trust boundary that fails here is the gateway's own authentication layer, the component that is supposed to guarantee only holders of valid LiteLLM keys can invoke MCP tools.

Attack prerequisites. Minimal. The attacker needs network reachability to the MCP Streamable HTTP endpoint and the ability to send an HTTP request with a crafted Authorization header. No valid LiteLLM key, no prior session, and no user interaction are required. The CVSS vectors from both NVD and GitHub reflect this: PR:N and UI:N across the board.

Affected version ranges:

• LiteLLM < 1.84.0 — vulnerable
• LiteLLM >= 1.84.0 — fixed

Network exposure. The MCP Streamable HTTP endpoint is typically reachable at /mcp/ or /{server_name}/mcp paths on the LiteLLM proxy. Any deployment where that endpoint is reachable from an untrusted network — internet, partner, or a broad internal segment — should be treated as exposed. The fix in 1.84.0 addresses both the public-route smuggling bypass and the OAuth2 fallback fail-open behavior.

Impact

Successful exploitation gives an unauthenticated attacker access to MCP tooling through the LiteLLM gateway. In practice, that means the attacker can invoke tools the gateway exposes to authenticated users, read data returned by those tools, enumerate available capabilities, and interact with downstream systems the gateway is trusted to reach. The high confidentiality rating reflects the likelihood that tool responses include sensitive content — model outputs, retrieved documents, internal API responses, or configuration data. The low integrity rating reflects that the flaw primarily grants access rather than allowing arbitrary modification of stored state, though tool side effects should not be ruled out.

Realistic abuse scenarios include using the gateway as a pivot into internal services that trust LiteLLM's authentication, harvesting upstream LLM provider credentials or metadata visible to the gateway, and mapping internal tooling for follow-on attacks. Because MCP tools may include integrations with databases, code execution environments, or third-party APIs, the blast radius can extend significantly beyond the proxy itself.

Business exposure includes regulatory and contractual obligations around unauthorized access to AI systems, potential data exposure through tool outputs, and the operational cost of incident response across every deployment of the affected versions. Because CISA added this to KEV, defenders should assume real-world exploitation is occurring and scope accordingly. The management-plane risk is notable: a gateway that mediates access to multiple providers and tools is a high-value target, and an authentication bypass on that gateway undermines the control assumptions of everything behind it.

Exploitability

CVE-2026-59822 is listed in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-02, due 2026-09-16), which is the strongest available signal that exploitation has been observed in the wild. The EPSS score is 0.0087, roughly the 57th percentile — a low probabilistic signal that is outweighed by the KEV listing and the presence of a public proof-of-concept.

A public exploit/PoC reference exists on GitHub at https://github.com/HORKimhab/CVE-2026-59822. The availability of a public PoC lowers the barrier for opportunistic exploitation and reinforces the need for rapid patching. The vulnerability was reported by security researcher yaaras and disclosed through GitHub's security advisory process; the fix was developed by contributor stuxf and reviewed with a 5/5 confidence score by Greptile AI, which noted both security fixes were correctly implemented and thoroughly tested.

KEV vs CVSS vs EPSS

Signal	What it measures	Action for this CVE
CISA KEV	Confirmed in-the-wild exploitation	Treat as exploited. Patch to 1.84.0 or isolate the MCP endpoint before 2026-09-16.
CVSS v3.1 (NVD) 8.2 / CVSS v4.0 (GitHub) 8.8	Intrinsic severity of the flaw	High severity, unauthenticated, network-reachable. Prioritize above routine patching.
EPSS 0.0087 (~57th percentile)	Probability of exploitation in the next 30 days	Low probabilistic signal; do not use it to deprioritize given KEV and public PoC.

Exploitation steps (defensive triage)

1. Inventory. Identify all LiteLLM deployments in the environment and determine which versions are below 1.84.0.
2. Exposure check. For each deployment, confirm whether the MCP Streamable HTTP endpoint is enabled and reachable, and from which network zones (internet, partner, internal).
3. Log hunt — gateway. Review gateway and reverse-proxy logs for requests to the MCP Streamable HTTP path that carry Authorization headers which do not correspond to any issued LiteLLM key.
4. Log hunt — correlation. Correlate those requests with downstream MCP tool invocations that lack a matching authenticated session or valid key context.
5. Behavioral review. Check for anomalous tool usage patterns — unusual tool names, high request rates, or calls originating from unexpected source IPs or user agents.
6. Upstream review. Inspect upstream provider logs and billing for unexpected model or tool activity that could indicate gateway abuse.
7. Preserve. Preserve relevant logs and artifacts in line with CISA's forensics triage guidance before remediating, then upgrade to 1.84.0 or later.
8. Verify. After patching, re-run the same log queries to confirm the anomalous pattern has stopped and validate that only valid keys reach MCP tooling.

Indicators of compromise

• HTTP requests to the MCP Streamable HTTP endpoint with Authorization headers that do not match any issued LiteLLM key.
• Gateway log entries showing OAuth2 passthrough fallback activity where key validation should have failed closed.
• MCP tool invocations with no corresponding authenticated session, user identity, or key metadata.
• Spikes in MCP tool call volume, especially from single source IPs or unfamiliar user agents.
• Requests to MCP paths originating from internet-facing source addresses when the endpoint is intended to be internal-only.
• Upstream LLM provider or tool API activity that cannot be tied to a known LiteLLM key or user.
• EDR or process telemetry showing unexpected child processes or outbound connections from the LiteLLM host following MCP requests.
• Authentication logs where failed key validation is immediately followed by successful tool execution in the same request context.

Mitigation and workarounds

Primary fix. Upgrade LiteLLM to version 1.84.0 or later. This release contains the fix for CVE-2026-59822, addressing both the public-route smuggling bypass and the OAuth2 fallback fail-open behavior.

Compensating controls if immediate upgrade is not possible:

• Restrict network access to the MCP Streamable HTTP endpoint so that only trusted networks or identities can reach it.
• Consider disabling the endpoint entirely until patching is complete.
• Place the gateway behind an authenticating reverse proxy or API gateway that enforces its own credential checks, so requests with fabricated Bearer tokens are rejected before reaching LiteLLM.

Credential hygiene. Review and rotate any upstream provider credentials or secrets the gateway holds, on the assumption that unauthenticated access may have occurred.

Compliance. Follow CISA's BOD 26-04 guidance for prioritizing security updates based on risk, and apply the associated forensics triage requirements. If mitigations cannot be applied and the endpoint cannot be safely isolated, discontinue use of the affected deployment until it can be remediated. Confirm the remediation deadline of 2026-09-16 is met for any federal or regulated environments.

Verification. After patching, re-scan to confirm the deployed version is 1.84.0 or later, and re-run the log queries in the triage section to confirm no further anomalous MCP access.

Community reactions

Coverage of CVE-2026-59822 has centered on its inclusion in CISA's Known Exploited Vulnerabilities catalog, which elevates it from a vendor advisory to an operational priority for defenders. The GitHub security advisory from BerriAI provides the authoritative technical description, noting the OAuth2 passthrough fallback and the empty UserAPIKeyAuth() object as the mechanism. Sysdig flagged this as a critical LiteLLM vulnerability in their AI security coverage, highlighting the risk to organizations using LiteLLM as an AI gateway with MCP integrations. A public proof-of-concept repository has appeared on GitHub, which lowers the barrier for opportunistic exploitation and reinforces the need for rapid patching. Security media and community discussion have highlighted the unusual nature of the flaw — an authentication bypass that hinges on a fallback path rather than a memory-safety bug — and the fact that LiteLLM often sits in a privileged position with access to multiple LLM providers and internal tools. Defenders in AI platform and MLOps communities have been sharing detection queries focused on MCP endpoint access logs and anomalous tool invocation patterns.

FAQ

Is CVE-2026-59822 in CISA's KEV catalog? Yes. CISA added it on 2026-09-02 with a remediation due date of 2026-09-16.

What is the CISA KEV due date? 2026-09-16. Federal and regulated environments should meet this deadline; other organizations should treat it as a strong prioritization signal.

Is the vulnerability exploitable over the internet? Yes, if the MCP Streamable HTTP endpoint is reachable from an untrusted network. The CVSS vectors from both NVD and GitHub indicate network reachability with no privileges or user interaction required.

Which products and versions are affected? BerriAI LiteLLM, all releases prior to 1.84.0. Version 1.84.0 contains the fix.

How do I verify remediation? Confirm the deployed LiteLLM version is 1.84.0 or later, then re-run the log queries in the triage section to confirm no further anomalous MCP access. If you applied compensating controls instead of patching, verify that the MCP endpoint is unreachable from untrusted networks.

Is there a public exploit? Yes. A public proof-of-concept reference exists on GitHub at https://github.com/HORKimhab/CVE-2026-59822.

Does this involve ransomware? CISA lists known ransomware use as unknown for this CVE.

Related resources

• BerriAI LiteLLM security advisory (GHSA-7488-6r32-c95q)
• NVD entry for CVE-2026-59822
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 implementation guidance, Forensics Triage Requirements
• Public proof-of-concept reference (community)
• Wiz vulnerability database entry for CVE-2026-59822