CVE-2026-59822: BerriAI LiteLLM MCP Streamable HTTP Endpoint Allows Authentication Bypass via Arbitrary Bearer Token

Background

LiteLLM, maintained by BerriAI, is an open-source LLM gateway and proxy widely used to provide a unified API interface across dozens of large language model providers (OpenAI, Anthropic, Azure, Bedrock, and many others), handling request routing, rate limiting, cost tracking, and authentication for organizations running LLM-backed applications. As organizations increasingly connect LLM applications to external tools and data sources via the Model Context Protocol (MCP), LiteLLM added support for MCP Streamable HTTP as a transport, allowing MCP clients to establish sessions with MCP servers proxied through LiteLLM.

CVE-2026-59822 is an improper authentication vulnerability in that MCP Streamable HTTP endpoint. According to the KEV description, the flaw allows an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token — meaning the attacker does not need a valid token at all; any token value, including one entirely invented by the attacker, is sufficient to obtain an authenticated session.

Technical Mechanism

CVE-2026-59822 is classified under both CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function), reflecting that the MCP Streamable HTTP endpoint’s session-establishment logic either fails to properly validate the Bearer token presented, or skips meaningful validation of it entirely for this transport path.

A representative exploitation flow:

1. An attacker identifies a LiteLLM deployment exposing the MCP Streamable HTTP endpoint — a transport designed to let MCP clients open a persistent, authenticated streaming session to interact with MCP-exposed tools and resources proxied through LiteLLM.
2. The attacker sends a session-establishment request to the MCP Streamable HTTP endpoint, including an Authorization: Bearer <token> header containing an arbitrary, attacker-chosen value — not a token issued by the LiteLLM instance or any legitimate identity provider.
3. Due to the improper/missing authentication check in the endpoint’s session logic, LiteLLM accepts the arbitrary token as valid and establishes an authenticated MCP session for the attacker, rather than rejecting the request for lacking a verifiable credential.
4. With an authenticated MCP session established, the attacker can interact with whatever MCP-exposed tools, resources, or backend systems the LiteLLM deployment has wired up to that session — which, depending on deployment configuration, may include tools that read or write files, query databases, call external APIs, or invoke other automation with real-world side effects.

This is a particularly severe class of flaw because MCP is explicitly designed to grant LLM-driven agents controlled access to tools and systems — an authentication bypass at the MCP session layer effectively hands an unauthenticated network attacker the same tool-calling capability that was intended to be restricted to authenticated, trusted agent sessions.

Real-World Exploitation Evidence

CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on 2 September 2026, confirming — by definition of KEV listing — that CISA has evidence of active exploitation in the wild, not merely a theoretical or proof-of-concept risk.

No specific threat actor, campaign name, or intrusion set is included in the available KEV record for this entry. No specific threat actor has been publicly attributed to exploitation of this CVE; its KEV listing confirms active exploitation in the wild, but attribution detail is not yet public. As LLM gateway and agent-tooling infrastructure becomes a more common component of production environments, authentication bypasses in this layer are a plausible and increasingly attractive target for attackers seeking either direct access to connected backend systems or a foothold from which to abuse AI-driven automation — but no specific actor or campaign has been confirmed for this CVE.

The knownRansomwareCampaignUse field for this entry is marked “Unknown” — CISA has not confirmed ransomware use of this CVE at this time.

Impact Assessment

An authentication bypass granting a fully authenticated MCP session to an unauthenticated attacker carries impact proportional to whatever tools and data the compromised LiteLLM deployment exposes via MCP:

• Confidentiality: An attacker with an authenticated MCP session can invoke any MCP tool or resource the session is entitled to, potentially retrieving sensitive data from connected databases, file systems, or third-party APIs that the organization intended to expose only to trusted, authenticated agents.
• Integrity: Many MCP tool integrations are not read-only — write-capable tools (file creation/modification, database writes, ticket creation, outbound API calls) could be invoked by the attacker to alter data, send unauthorized communications, or trigger unintended automation.
• Availability: Depending on the tools exposed, an attacker could exhaust rate limits, trigger resource-intensive operations, or disrupt the underlying LLM provider integration for legitimate users of the LiteLLM gateway.
• Supply chain / blast radius consideration: Because LiteLLM is a gateway sitting in front of potentially many downstream LLM providers and tool integrations for an organization, a single exploited instance can expose the full breadth of whatever has been connected through it — a wider blast radius than a bug in any single downstream tool integration.

Sector-specific risk: This vulnerability is most acute for organizations that have moved beyond simple chat-completion use cases into agentic, tool-calling LLM deployments — a rapidly growing category across software engineering platforms, customer support automation, and internal developer tooling. Any organization that has wired sensitive internal systems to MCP tools behind a LiteLLM gateway without additional network-layer authentication should treat this as a high-priority exposure regardless of industry vertical.

Affected Versions

The exact affected LiteLLM version range is not included in the provided KEV data. Organizations should consult BerriAI’s GitHub Security Advisory (linked below) for the definitive affected-version list and the specific patched release.

Any self-hosted LiteLLM deployment with MCP Streamable HTTP enabled, running a version predating BerriAI’s fix, should be treated as presumptively vulnerable until confirmed patched.

Remediation Steps

CISA’s required action directs organizations to apply vendor mitigations per BOD 26-04 guidance, follow Forensics Triage Requirements, or discontinue use of the product if mitigations are unavailable.

1. Identify the LiteLLM version in use and check whether MCP Streamable HTTP is enabled in your deployment configuration:

pip show litellm
# or, for containerized deployments:
docker exec <litellm-container> pip show litellm

2. Upgrade to the patched LiteLLM release referenced in the GitHub Security Advisory (see References) as soon as possible.

3. Rotate and re-validate any Bearer tokens or credentials used for MCP authentication in your environment — since arbitrary tokens were accepted during the vulnerable window, assume any session established during that period may have been illegitimate, and audit MCP session logs accordingly.

4. Apply network-layer access controls to the MCP Streamable HTTP endpoint as defense-in-depth, independent of the application-layer fix:

# Example: restrict MCP endpoint access to known internal agent/service IP ranges only
# Deny inbound access to the LiteLLM MCP Streamable HTTP port from untrusted or internet-facing networks

5. Review the scope of tools and resources exposed via MCP through this LiteLLM instance, and apply least-privilege principles — ensure that even legitimately authenticated MCP sessions cannot reach more sensitive systems than strictly necessary, limiting the impact of any future authentication-layer flaw.

Detection Guidance

Exact signatures should come from BerriAI’s advisory or your application security monitoring tooling, since full exploitation specifics are not publicly detailed. General detection approaches:

• Application logs: Review LiteLLM MCP session establishment logs for sessions authenticated with Bearer tokens that do not match any token issued by your identity provider or LiteLLM’s own token management — a strong indicator of exploitation of this flaw.
• Anomalous MCP tool invocation patterns: Monitor for MCP tool calls originating from sessions with no corresponding legitimate user or service account context, or tool invocation patterns inconsistent with expected agent behavior (e.g., bulk data retrieval, unusual off-hours activity).
• Network logs: Review access logs for the MCP Streamable HTTP endpoint for requests originating from unexpected source IP ranges, particularly from outside your known agent/service infrastructure.
• Token audit: Where feasible, retroactively cross-reference all Bearer tokens observed in MCP session logs against your actual issued-token inventory to identify any session established with a non-issued, arbitrary token during the vulnerable window.

Timeline

References

• BerriAI LiteLLM GitHub Security Advisory — GHSA-7488-6r32-c95q
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA — BOD 26-04 Implementation Guidance: Forensics Triage Requirements
• NVD — CVE-2026-59822