On 2 September 2026 CISA added CVE-2026-59822 in BerriAI's LiteLLM to the Known Exploited Vulnerabilities catalog, with a federal due date of 16 September. The bug sits in LiteLLM's MCP Streamable HTTP endpoint. An unauthenticated attacker could send a fabricated Authorization header and get an authenticated MCP session.
This is the third LiteLLM entry in KEV in 2026, after CVE-2026-42208 on 8 May and CVE-2026-42271 on 8 June. CVE-2026-42271 is a command injection in LiteLLM's MCP test endpoints, so like this one it sits in the part of the AI gateway that connects models to tools.
What's affected
- Package:
litellmon PyPI, the proxy server most teams run as an AI gateway. - Vulnerable: all versions before 1.84.0.
- Fixed: 1.84.0, which PyPI shows was uploaded on 14 May 2026. GitHub published advisory GHSA-7488-6r32-c95q on 22 July.
- Severity: 8.8 under CVSS 4.0 from the GitHub advisory, 8.2 under CVSS 3.1 from NVD.
What went wrong, per the advisory: LiteLLM supports OAuth2 passthrough for upstream MCP servers. When LiteLLM key validation failed, a fallback path replaced the failure with an empty UserAPIKeyAuth() object instead of rejecting the request. So any request with a made-up Bearer token reached MCP tooling as if it were authenticated.
The impact is whatever your MCP tools can do. The advisory says an attacker could list and call configured MCP tools and access connected services exposed through MCP. If your gateway wires MCP servers to GitHub, a database, a ticketing system or a shell, the attacker inherits those.
How to check if you're exposed
Check the installed version wherever LiteLLM runs:
pip show litellm | grep -i ^version
# in a container
docker exec litellm-proxy python -c "import litellm, importlib.metadata as m; print(m.version('litellm'))"
Then check whether MCP is in use at all. Look in your proxy config.yaml for an mcp_servers section, and in your reverse proxy for traffic to /mcp/:
grep -n "mcp_servers" config.yaml
grep -E '"[A-Z]+ /mcp/' /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head
For hunting, compare callers against what you expect. Requests to /mcp/ from IP addresses that never call your normal /chat/completions or /v1/ routes are suspicious, since real clients usually use both. If your MCP servers log tool calls on their side, look for calls that have no matching user or key in LiteLLM's own spend or request logs. A tool call LiteLLM can't attribute to a key is the pattern this bug produces.
What to do now
- Upgrade to
litellm1.84.0 or later. If you also run anything older than 1.83.7, this upgrade fixes CVE-2026-42271 at the same time. - If you can't upgrade today, follow the advisory's workaround: disable MCP routes or block
/mcp/and related MCP endpoints at your reverse proxy or API gateway. - Keep the LiteLLM admin and MCP surfaces off the public internet. Put them behind your SSO proxy or a private network.
- If you find unattributed MCP tool calls, rotate every credential your MCP servers use to reach downstream systems, and review what those tools changed during the exposure window.
- Give each MCP server the narrowest token that still works. A read only GitHub token limits what an auth bypass can do.
Why it matters
An AI gateway centralizes two things attackers want: model provider keys and tool access. MCP adds a third, because each connected server carries its own credentials to real systems. When the gateway's auth fails open, the blast radius is every tool behind it, not just model usage.
Fail open fallbacks are an old bug class. Here the intent was reasonable, supporting OAuth2 passthrough to upstream servers, but the error path produced an empty identity object instead of a rejection. Code review for auth handlers should treat "what happens when validation fails" as the first question, not the last.
Try it yourself
List every MCP server your LiteLLM proxy exposes and write down, for each one, which credential it holds and what that credential can change. If the list surprises you, scope those tokens down before the next auth bug arrives.
This demo shows how a guardrail in front of MCP traffic inspects and blocks tool calls:
Click through it at your own pace, or open it full screen.
Quick check
Which LiteLLM version fixes CVE-2026-59822?
1.84.0. The GitHub advisory recommends upgrading to 1.84.0 or later.
What is the workaround if I can't upgrade yet?
Disable MCP routes, or block /mcp/ and related MCP endpoints at your reverse proxy or API gateway, as the advisory recommends.
Is this the same bug as CVE-2026-42271?
No. CVE-2026-42271 is a command injection in the MCP test endpoints, fixed in 1.83.7 and added to KEV on 8 June 2026. CVE-2026-59822 is an authentication bypass in the MCP Streamable HTTP endpoint, fixed in 1.84.0.
