CVE-2026-59822: BerriAI LiteLLM Improper Authentication Vulnerability

CVE-2026-59822 is an improper authentication weakness in BerriAI LiteLLM affecting the MCP Streamable HTTP endpoint. An unauthenticated attacker may be able to establish an authenticated MCP session by supplying an arbitrary Bearer token. For teams running LiteLLM as a gateway or proxy to model and tool services, that means session trust can be obtained without valid credentials, which can expose connected backends, tools, and data paths depending on how the product is deployed. Confirm exact scope, fixed releases, and configuration details against the vendor advisory before acting.

CISA describes the issue as improper authentication and points operators to vendor mitigations, BOD 26-04 risk-based update prioritization, and related forensics triage expectations. Ransomware use is not documented in the provided facts.

How it works

The weakness is classified under CWE-287 (Improper Authentication) and CWE-306 (Missing Authentication for Critical Function). In plain terms, a critical path—the MCP Streamable HTTP endpoint—does not adequately verify that a presented Bearer token is legitimate before treating the caller as an authenticated MCP session.

An attacker who can reach that endpoint may present an arbitrary Bearer token and obtain an authenticated MCP session without prior enrollment or secret knowledge. From a defender’s perspective, that bypasses the normal gate that should bind sessions to issued credentials. What the attacker can then do depends on LiteLLM’s role in your environment (for example, routing, tool access, or upstream model APIs) and on network placement. Do not assume exploit mechanics beyond the advisory summary; treat any internet-exposed or broadly reachable MCP Streamable HTTP surface as high priority for verification.

Am I affected? How to find it in your systems

LiteLLM is commonly used as a unified interface or proxy for LLM providers and related tooling. It may run as a service in cloud accounts, Kubernetes, VMs, developer workstations, or internal platforms that expose HTTP APIs for model and MCP-style workflows.

• Inventory: Search configuration management, container images, package manifests, IaC, and service catalogs for BerriAI LiteLLM (process names, image names, Python/package installs, and reverse-proxy routes that front LiteLLM).
• Exposure: Identify listeners and ingress rules for the MCP Streamable HTTP endpoint; note public IPs, load balancers, API gateways, and zero-trust allowlists. Stakeholders should evaluate internet exposure per CISA’s BOD 26-04-oriented guidance in the facts.
• Versions and config: Record installed versions and auth-related settings. Exact affected and fixed versions are not provided here—confirm against the vendor advisory.
• Telemetry: Review access logs for the MCP Streamable HTTP path for unexpected Bearer tokens, sessions established without a normal token-issuance flow, spikes in unauthenticated or anomalous clients, and subsequent unusual tool or upstream API use. Correlate with identity and network logs. Absence of known public exploit detail does not mean absence of abuse.

How to remediate

Patch first. Apply the vendor-supplied update or mitigation instructions for BerriAI LiteLLM as named in the official advisory. Validate in a non-production environment if needed, then roll out under change control and re-check that the MCP Streamable HTTP endpoint enforces proper authentication.

• After patching, regenerate or rotate any tokens, keys, or session material that may have been relied on while the weakness was present, following your normal secret-rotation process.
• Enforce authentication and authorization at every edge that fronts LiteLLM (API gateway, reverse proxy, service mesh), not only inside the app.
• Reduce blast radius: least-privilege credentials to upstream models and tools, separate environments, and disable unused MCP or HTTP features.
• Align with CISA’s required action: apply vendor mitigations, follow BOD 26-04 risk-based prioritization and forensics triage expectations where they apply, and for cloud or unmanaged cases follow applicable BOD 26-04 cloud guidance—or discontinue use if mitigations are unavailable.

If you can't patch immediately

Until the vendor fix is in place, reduce reachability and increase detection.

• Segmentation: Remove internet exposure; restrict the MCP Streamable HTTP endpoint to known admin or application networks via firewall, security groups, or private service endpoints.
• Access control: Put a strong authenticating proxy in front; deny anonymous access; require mutual TLS or enterprise SSO where architecture allows.
• Virtual patching / WAF: If you use a WAF or API gateway, add rules to block or challenge anomalous Bearer usage and unknown clients on the MCP Streamable HTTP path—tuned to your traffic and verified so you do not break legitimate flows. This is compensating only, not a substitute for the vendor fix.
• Feature control: Disable or unload the affected MCP Streamable HTTP capability if your deployment does not require it.
• Monitoring: Alert on new sessions, odd token patterns, and post-session tool or data access; retain logs for incident review consistent with your forensics requirements.

If your data may have been exposed

Actively exploited authentication flaws can lead to unauthorized access and follow-on data exposure, even when ransomware use is not documented. If this service was reachable and unpatched, investigate session and upstream access logs, rotate credentials, and follow your incident process. You can run a free exposure scan of your email to check known breach data for personal addresses associated with your team.