What is CVE-2026-59822?

An authentication bypass in the MCP Streamable HTTP endpoint of the LiteLLM proxy. When LiteLLM's key check failed, a fallback meant for OAuth passthrough replaced the failure with an empty auth object, so any bearer token, even a single character, opened an MCP session. It is fixed in LiteLLM 1.84.0, released on 14 May 2026.

Is CVE-2026-59822 being exploited?

Yes. Wiz observed exploitation in a honeypot on 7 July 2026, and CISA added it to its Known Exploited Vulnerabilities catalog on 2 September 2026 with a 16 September deadline for federal agencies. It is reported as the first MCP vulnerability on the KEV list.

Which LiteLLM versions were compromised on PyPI?

Versions 1.82.7 and 1.82.8, published on 24 March 2026 after attackers obtained the maintainer's publishing credentials. They carried a credential harvester targeting SSH keys, cloud credentials, Kubernetes secrets and .env files. The releases were yanked after a few hours. If either was installed anywhere, treat every secret on that machine as stolen and rotate it.

Am I affected by the LiteLLM vulnerability?

For CVE-2026-59822, only if you run the LiteLLM proxy, not just the Python library, on a version before 1.84.0 with its MCP endpoint reachable. For the PyPI compromise, anyone who installed 1.82.7 or 1.82.8, including as a transitive dependency of another tool. Check your lockfiles and build logs for those two versions.

What should I do about the LiteLLM vulnerability?

Upgrade the proxy to 1.84.0 or later, replace the default master key, keep the proxy off the public internet, and review which MCP servers and credentials it can reach. Search lockfiles and CI logs for 1.82.7 and 1.82.8, and rotate secrets on any machine that installed them.

LiteLLM Vulnerability CVE-2026-59822: Check Your Exposure

A gateway between AI model clouds and a company server with its door open and a cracked padlock, key cards slipping through, beside a sealed box with a glowing lock and a pinned version tag

CVE-2026-59822 is an authentication bypass in the LiteLLM proxy's MCP endpoint: a failed key check fell through to an empty auth object, so any bearer token, even one character, was accepted. It is fixed in LiteLLM 1.84.0, it has been exploited since at least July, and on 2 September 2026 CISA added it to its Known Exploited Vulnerabilities catalog, the first MCP flaw on that list. It is LiteLLM's second serious incident this year: in March, two releases on PyPI, 1.82.7 and 1.82.8, shipped a credential stealer. LiteLLM is one of the most used ways to call many AI models through one interface. We use it in production ourselves. Below: what each incident does, how to check your exposure, and what we found when we checked our own stack.

Two incidents, two different exposures

The auth bypass only affects the LiteLLM proxy: the server many teams run as a central gateway to their AI models, with keys, budgets and, since 2026, MCP tools. If you only import the litellm Python library inside your own code, there is no MCP endpoint to bypass.

The PyPI compromise affects anyone who installed the two bad versions, library or proxy, directly or as a dependency of something else. FutureSearch found it because an MCP plugin in Cursor pulled LiteLLM in transitively.

CVE-2026-59822: any token opened the door

From Wiz's research, published 9 September 2026:

The bug. LiteLLM's MCP auth handler caught the 401 or 403 from its key validation and returned an empty auth object, which the rest of the code treated as authenticated. A single character was enough to open a valid MCP session.
What it reaches. Whatever MCP servers the proxy has configured: Jira, Slack, databases, CI/CD. With allow_all_keys, every server is open to every caller.
Timeline. Fixed in 1.84.0 on 14 May. Wiz's honeypot saw exploitation on 7 July. CISA listed it on 2 September, with a 16 September deadline for federal agencies.

Wiz found more in the same proxy:

The default master key, sk-1234. In a February 2026 scan of 3,074 exposed instances, 294 (9.6%) still accepted it and 191 (6.2%) had no authentication at all. The master key also signs session tokens.
CVE-2026-59821: custom code guardrails skipped the sandbox, allowing code execution as root, fixed in 1.82.0.
Pass-through endpoints could be pointed at the cloud metadata service to fetch IAM credentials. LiteLLM did not treat this as a vulnerability, so it is on you to restrict.

The pattern is worth naming because it is the most common MCP auth bug we see: a failure path that returns success. Code that handles "this credential is not mine" and "this credential is invalid" in the same branch ends up accepting both.

The PyPI compromise: 1.82.7 and 1.82.8

On 24 March 2026, attackers who had obtained the maintainer's PyPI publishing credentials, reportedly through an earlier compromise of the Trivy scanner used in LiteLLM's CI, published two malicious versions (Bitsight). The payload harvested SSH keys, cloud credentials, Kubernetes secrets, crypto wallets and .env files, with Kubernetes lateral movement and a persistent backdoor. The GitHub source was not changed. The versions were yanked after a window reported at three to five hours.

With roughly 95 million downloads a month, a few hours is a lot of installs.

How to check your exposure

If you run the LiteLLM proxy:

Check the version. Anything below 1.84.0 is affected by CVE-2026-59822. Upgrade.
Check whether the proxy, and its /mcp path, is reachable from the internet. It should not be.
Replace sk-1234 if it is still the master key, and rotate anything signed with it.
Review which MCP servers are configured, what credentials they hold, and whether allow_all_keys is on.
Restrict pass-through endpoints and container egress, so the proxy cannot reach the cloud metadata service.

For the PyPI compromise, library or proxy:

Search every lockfile (uv.lock, poetry.lock, requirements*.txt) and CI log for litellm 1.82.7 or 1.82.8.
Remember transitive installs: developer tools, notebooks, MCP plugins.
If either version was ever installed on a machine, treat every secret on it as stolen: rotate cloud keys, SSH keys, tokens and anything in .env files, then rebuild the machine or image.

What we found in our own stack

We call AI models from one Python service through the LiteLLM library. This is what we checked, and what we found:

The PyPI compromise did not reach us. Our image installs from a lockfile, and the lockfile had LiteLLM pinned at 1.80.0 throughout March, so 1.82.7 and 1.82.8 were never installed. On 10 April we upgraded to 1.83.4 and set the minimum to >=1.83.0, with a comment in the dependency file saying it skips the compromised versions. Production now runs 1.90.2.
The auth bypass does not apply to us. We use the library inside our own service, not the proxy, so there is no LiteLLM MCP endpoint, master key or pass-through route to expose.
Our own MCP servers are not built on LiteLLM. They are Go services, and the bug class above is exactly what we test for. Each credential type has a verifier that first answers "is this mine?" without validating, then validates only what it claimed. An invalid credential is rejected, never waved through. We extracted that design into an open-source library, rflkt/mcp, whose conformance tests drive the real handler to prove it.

What saved us from the PyPI incident was not cleverness. It was a lockfile that nobody had bumped that week. Lockfiles, pinned minimum versions with a reason written next to them, and automated dependency alerts are boring, and they are the whole defence against this kind of attack.

LiteLLM Vulnerability (CVE-2026-59822): The First MCP Flaw on CISA's Exploited List

In 2026 LiteLLM had a credential-stealing release on PyPI and an auth bypass that CISA now lists as exploited. We use LiteLLM in production. Here is what each one does, how to check whether you are exposed, and what we found when we checked ourselves.