1. Executive summary
BerriAI LiteLLM — an open-source AI gateway providing a unified OpenAI-format interface to multiple LLM APIs — contains an improper authentication vulnerability (CVE-2026-59822, CVSS 8.8 HIGH, CWE-287/CWE-306) in its MCP Streamable HTTP endpoint. The flaw allows an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token, then list and call configured MCP tools and access connected services exposed through MCP. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on 2026-09-02, with a federal remediation due date of 2026-09-16. This is the third LiteLLM vulnerability CISA has catalogued as exploited in under four months, after CVE-2026-42208 (SQL injection) and CVE-2026-42271 (authenticated command injection) — a pattern that makes any internet-exposed LiteLLM proxy deployment a priority risk for EMEA financial services.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 18: classification of ICT-related incidents and cyber threats | CISA KEV listing (2026-09-02) confirms active exploitation of a vulnerability in a product in scope for financial entities' AI/LLM gateway infrastructure | Clients running LiteLLM must classify exposure to this exploited CVE within their ICT-related incident and cyber-threat classification process, on the basis of confirmed in-the-wild exploitation rather than theoretical risk |
| DORA Art. 24: digital operational resilience testing — general requirements | The vulnerability is an authentication bypass reachable on the MCP Streamable HTTP endpoint, and the vendor's stated workaround is network-level blocking of /mcp/ routes — i.e. exposure is determined by deployment architecture, not merely version |
Resilience testing should verify that LiteLLM instances (including those embedded in third-party AI platforms) are version-pinned at ≥1.84.0 and that MCP endpoints are not reachable unauthenticated from untrusted networks |
No NIS2 or UK NIS article is directly engaged by the specific facts of this item beyond generic patching duties.
3. Technical analysis & attack chain
Vulnerability mechanism. LiteLLM's MCP authentication handler supports OAuth2 passthrough for upstream MCP servers. The fallback path in that handler could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object. The practical effect: when LiteLLM key validation failed, the request was not rejected — it was instead associated with an empty (unauthenticated) auth object and passed through to MCP tooling. A request carrying a fabricated Authorization: Bearer <any-value> header could therefore reach MCP tools without ever presenting a valid LiteLLM key.
Confirmed attack chain
- The attacker sends a request to the LiteLLM MCP Streamable HTTP endpoint (routes under
/mcp/) with an arbitrary/fabricated Bearer token in theAuthorizationheader. - LiteLLM key validation fails on the fabricated token.
- The OAuth2-passthrough fallback path substitutes an empty
UserAPIKeyAuth()object rather than rejecting the request. - The attacker now holds an authenticated MCP session without valid credentials.
- Using that session, the attacker can enumerate (list) the MCP tools configured on the proxy and invoke (call) them.
- Tool invocation provides access to the connected services exposed through MCP — the upstream systems, APIs, and data sources the organisation has wired into its MCP tooling.
Why this matters in combination. LiteLLM proxies sit in a privileged position: they centralise LLM API credentials, proxy database contents, and — via MCP — connections to operational tooling. Two previously exploited LiteLLM vulnerabilities demonstrate the blast radius:
- CVE-2026-42208 (SQL injection, CISA KEV due date 2026-05-11): allowed an attacker to read data from the proxy's database and potentially modify it, leading to unauthorised access to the proxy and the credentials it manages.
- CVE-2026-42271 (command injection, CVSS 8.7 per The Hacker News, CISA KEV due date 2026-06-22): allowed any authenticated user — including holders of low-privilege internal-user keys — to run arbitrary commands on the host. BSI Germany assessed it as enabling execution of arbitrary code with administrator privileges by a remote, authenticated attacker.
The authentication bypass in CVE-2026-59822 is the unauthenticated front door to that same class of privileged access: an attacker who reaches MCP tooling without credentials can pivot into whatever the MCP configuration exposes. Note that CVE-2026-42271 requires any authenticated user — an attacker who first establishes a session via CVE-2026-59822 has satisfied that precondition on an unpatched deployment. We have no source evidence of this specific chain being executed in the wild; the chaining assessment is our analysis of the combined mechanics, not an observed campaign.
Exploitation status. CVE-2026-59822 is in CISA KEV (added 2026-09-02), confirming active exploitation. EPSS is 1% at time of writing. CISA's required action references BOD 26-04 prioritisation and forensics triage requirements, with a due date of 2026-09-16. Known ransomware campaign use: unknown.
Confidence caveat. The technical mechanism above is drawn from the vendor's own GitHub Security Advisory (GHSA-7488-6r32-c95q) — single-sourced for the internal code-path detail (the UserAPIKeyAuth() fallback behaviour), though consistent with the NVD/CISA description. No threat-actor attribution exists in any source; no IOCs for exploitation of this CVE have been published. Treat exploitation details as unconfirmed until vendor or CERT telemetry emerges.
4. Mitigation & containment
P1 — within 24 hours
- Inventory. Locate all LiteLLM deployments, including instances embedded in third-party AI platforms, internal developer tooling, and LLM gateway stacks. LiteLLM is open-source and frequently deployed by individual teams outside central change control — assume undercounting and check for container images, Helm releases, and
pip/uvinstalls. - Version check. Any instance below
1.84.0is vulnerable. The fix shipped in1.84.0(release: https://github.com/BerriAI/litellm/releases/tag/v1.84.0). - Immediate containment for instances that cannot be patched today: disable MCP routes entirely, or block access to
/mcp/and related MCP endpoints at the reverse proxy or API gateway (vendor-recommended workaround). Do not rely on LiteLLM key validation to protect these routes on vulnerable versions — the vulnerability defeats it. - Exposure triage. Any LiteLLM instance with
/mcp/reachable from the internet or from untrusted/partner networks should be treated as potentially compromised. CISA's required action directs stakeholders to evaluate each asset's internet exposure and follow BOD 26-04 forensics triage requirements where exposure is confirmed. For exposed instances: review MCP tool invocation logs, proxy database access, and credential stores for anomalous activity dating back to deployment.
P2 — within 72 hours
- Patch to
1.84.0or later across all instances, prioritising internet-facing and MCP-enabled deployments. Version-pin in deployment manifests to prevent regression. - Audit MCP configuration on each proxy: enumerate which tools are configured, which upstream services they reach, and what credentials they hold. Every configured tool is a post-authentication pivot target under this CVE — remove tools that are not actively required.
- Rotate credentials reachable through MCP tooling and the LiteLLM proxy database (upstream API keys, service credentials) on any instance that was exposed while vulnerable. Given CVE-2026-42208's demonstrated credential-exposure impact on this same product, treat the proxy's credential store as at-risk on any historically exposed instance.
P3 — within 7 days
- Verify the fix: confirm patched instances reject requests to
/mcp/with invalid Bearer tokens (a fabricated token should now receive an authentication failure, not an empty auth object). - Harden the perimeter: ensure MCP endpoints are not internet-exposed by design — restrict to authenticated internal networks at the gateway layer regardless of patch level.
- Close out the earlier LiteLLM KEV items if not already done: CVE-2026-42208 (due 2026-05-11) and CVE-2026-42271 (due 2026-06-22). A deployment still vulnerable to 59822 may also be vulnerable to both; the combined exposure is unauthenticated access to MCP tooling plus authenticated command injection plus database/credential access.
5. Indicators of compromise
No indicators of compromise available in the source material.
Behavioural indicators (derived from the vulnerability mechanism; useful for retrospective review of exposed instances):
| Behaviour | Where to observe | Confidence |
|---|---|---|
Requests to /mcp/ endpoints carrying Authorization: Bearer headers with tokens that fail LiteLLM key validation but were not rejected (HTTP 2xx responses) |
Reverse proxy / API gateway access logs; LiteLLM proxy logs | High — direct consequence of the confirmed mechanism |
| MCP tool listing/invocation calls from sessions with no corresponding valid LiteLLM key in the auth store | LiteLLM proxy logs; MCP tool invocation logs | High — the confirmed post-exploitation capability |
| Access to upstream services exposed via MCP originating from the LiteLLM host without a matching authenticated user session | Upstream service logs, correlated to proxy logs | Medium — inferred from vendor impact statement |
6. Detection
The sources provide no file artefacts, hashes, command-line strings, or distinctive threat strings. The vulnerability is a server-side authentication logic flaw, not delivered malware — there is no malicious file to match. Behavioural detection is covered in §5.
Insufficient indicators to author detection rules.
CVE assessment
1 referenced CVE — 1 actively exploited (CISA KEV)
| CVE | CVSS | Exploited | EPSS | Summary |
|---|---|---|---|---|
| CVE-2026-59822 | 8.8 High | ⚠ KEV 2026-09-02 | 1% | 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… |
7. Sources
- NVD — CVE-2026-59822 — BerriAI LiteLLM Improper Authentication Vulnerability — https://nvd.nist.gov/vuln/detail/CVE-2026-59822 — 2026-09-01
- GitHub Security Advisories — LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback (GHSA-7488-6r32-c95q) — https://github.com/advisories/GHSA-7488-6r32-c95q — accessed 2026-09-02
- NVD / CISA KEV — CVE-2026-42271 — BerriAI LiteLLM Command Injection Vulnerability — https://nvd.nist.gov/vuln/detail/CVE-2026-42271 — KEV due date 2026-06-22
- NVD / CISA KEV — CVE-2026-42208 — BerriAI LiteLLM SQL Injection Vulnerability — https://nvd.nist.gov/vuln/detail/CVE-2026-42208 — KEV due date 2026-05-11
- The Hacker News — LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE — https://thehackernews.com/2026/06/litellm-flaw-cve-2026-42271-exploited.html — June 2026
- Help Net Security — LiteLLM vulnerability under active attack, CISA warns (CVE-2026-42271) — https://www.helpnetsecurity.com/2026/06/09/litellm-vulnerability-under-active-attack-cisa-warns-cve-2026-42271/ — 2026-06-09
- BSI Germany — WID-SEC-2026-1408 — LiteLLM: Schwachstelle ermöglicht Ausführen von beliebigem Programmcode mit Administratorrechten — https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-1408 — accessed 2026-09-02
8. Adverse Trace position
CVE-2026-59822 is a HIGH-severity (CVSS 8.8) improper authentication vulnerability in a product with a demonstrated, repeated exploitation history — three CISA KEV listings since May 2026 — and it sits in infrastructure (AI gateways) that financial services firms are adopting rapidly and often outside mature change control. The confirmed impact is unauthenticated access to MCP tooling and connected services; combined with the previously exploited SQL-injection and command-injection flaws in the same product, the realistic worst case on an unpatched, exposed deployment is credential theft and host-level code execution. No attribution and no IOCs have been published for this CVE; the exploitation detail is single-sourced to the vendor advisory and CISA KEV listing, so clients should verify exposure through their own logs rather than indicator hunting. Our recommendation: treat any sub-1.84.0 LiteLLM instance with reachable /mcp/ routes as a P1 incident-response trigger, not a routine patch item. We will monitor for IOCs, exploitation telemetry, and any threat-actor attribution, and will reissue this advisory if material indicators emerge before the 2026-09-16 KEV due date.
Published via PulseTrace — Adverse Trace threat intelligence.