LiteLLM MCP Auth Bypass CVE-2026-59822 Hits CISA KEV as Attackers Farm AI Gateways
🛡️ Security •

LiteLLM MCP Auth Bypass CVE-2026-59822 Hits CISA KEV as Attackers Farm AI Gateways

Any bearer token opened an authenticated MCP session on LiteLLM below 1.84.0. Wiz honeypots caught attackers probing it, mining Monero, and lifting provider keys from memory.

AB
Anthony Bahn IT Director & Cybersecurity Consultant
litellmmcpai securityactively exploitedcisa kev

On September 2, 2026, CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog. It is an authentication bypassAuthentication Bypass📖A security vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. in LiteLLM, the open-source proxy that many organizations use as a single front door to OpenAI, Anthropic, Azure, Google and self-hosted models. The flaw sits in LiteLLM's Model Context Protocol (MCP) gateway, and the exploitation evidence comes from a 90-day Wiz honeypotHoneypot🛡️A decoy system deployed to be attacked so defenders can observe exploitation attempts safely. Honeypot networks give early warning that a vulnerability has moved from theoretical to actively exploited, often before official catalogs like CISA KEV confirm it. study that watched attackers probe LiteLLM with one-character bearer tokens, drop Monero miners through a second LiteLLM flaw, and pull provider API keys straight out of the proxy's memory. The catalog entry gives federal agencies until September 16 to fix it. Anyone else running an internet-reachable LiteLLM below version 1.84.0 should treat the same date as generous.

What Happened

The GitHub advisory GHSA-7488-6r32-c95q, published June 30, 2026, describes the bug plainly. LiteLLM's MCP Streamable HTTP endpoint supports OAuth2 passthrough so that a client's token can be forwarded to an upstream MCP server. When a request's Authorization header failed LiteLLM's own key validation, the handler could fall through to that passthrough path and substitute an empty `UserAPIKeyAuth()` object for the failed check. The result was an authenticated MCP session for anyone who sent any bearer value at all. The advisory rates it CVSS v4 8.8 with high confidentiality impact: an attacker can list and invoke every MCP tool the gateway has configured and reach whatever services those tools connect to. The GitLab advisory database scores the same bug 8.2 under CVSS 3.1; CISA's entry tags it CWE-287 and CWE-306.

The fix commit, 73869f0, is worth reading because it repairs two separate mistakes. First, the check that exempted OAuthOAuth🛡️An open standard authorization protocol that allows applications to access user resources without exposing passwords, using tokens instead of credentials. discovery routes from authentication used a substring match for `.well-known` against the whole URL, so the marker could be smuggled in a query string or a deeper path segment. The patched code requires the path itself to start with `/.well-known/`. Second, the OAuth2 fallback now runs only when every MCP server targeted by the request is configured with `auth_type=oauth2`, resolved from the `/mcp/{server_name}` path pattern or the `x-mcp-servers` header. If the target cannot be resolved, the code fails closed and returns nothing. The fallback used to catch any 401 or 403 and convert it into an anonymous session regardless of how the target server was configured. That is the textbook shape of a fail-openFail-Open🛡️A design flaw in which a control that cannot complete its check grants access instead of denying it. In authentication, a missing key or failed lookup that results in access being allowed turns a security check into a rubber stamp. authentication path, the same class of defect behind last week's JFrog Artifactory phantom join-key bypass, and it is explained in How MCP Gateways Work and Why They Concentrate Risk.

Who Is Affected

Every LiteLLM proxy deployment below 1.84.0 with the MCP gateway reachable from an untrusted network. The version matters more than usual because LiteLLM has shipped a run of separate security fixes this year, and it is easy to be on a build that closed one hole and not the next:

  • CVE-2026-35029, an authorization gap on the `/config/update` admin endpoint, fixed in 1.83.0. Per aicybr's summary of Zenity Labs telemetry, probes began April 7, one day after disclosure, and reached roughly 3,900 requests from 73 IPs by June.
  • CVE-2026-42271, command injectionCommand Injection🛡️A security vulnerability that allows attackers to execute arbitrary operating system commands on the host system through a vulnerable application. through the MCP test endpoints `/mcp-rest/test/connection` and `/mcp-rest/test/tools/list`, affecting 1.74.2 through 1.83.6 and fixed in 1.83.7 on May 8, per the Cloud Security Alliance's research note. It requires a valid proxy key on its own, but Horizon3 showed it chains with the Starlette host-header smuggling bug CVE-2026-48710 into unauthenticated RCE. CISA added the Starlette bug to KEV in the same September 2 batch, also due September 16.
  • CVE-2026-59822, this bypass, fixed in 1.84.0, which aicybr dates to May 14, 2026.

As aicybr puts it, 1.84.0 is the effective security floor. A team that upgraded to 1.83.0 in April to close the admin API hole is still exposed to both MCP flaws. Add the March 24 TeamPCP incident, in which trojanized LiteLLM 1.82.7 and 1.82.8 sat on PyPI for about three hours harvesting cloud credentials and SSH keys before quarantine, and the picture is of a project under sustained, targeted pressure from several directions at once.

Technical Analysis

Wiz's honeypot telemetry, published August 27, is the primary account of what exploitation looks like in the wild. Three findings stand out.

The probes for CVE-2026-59822 were minimal. Wiz recorded requests of the form `GET /v1/models` with `Authorization: Bearer x`, a single-character token, aimed at model enumeration. Attackers were not crafting elaborate payloads. They were testing whether the gateway would accept garbage and answer, which is exactly the behavior the fallback bug produced. The Hacker News reports the same activity and adds that follow-on database harvesting targeted the `LiteLLM_ProxyModelTable` and `LiteLLM_VerificationToken` tables, which hold model configuration, provider keys and endpoints.

The RCE chain through CVE-2026-42271 was operationally mature. Wiz observed a malicious MCP stdio server configuration that fetched a payload from 185.62.1[.]8, staged an XMRig miner at `/tmp/.dbus-cache/gmon`, launched it with `start_new_session=True`, and then deleted the staging directory with `shutil.rmtree()` while the process kept running from memory. The miner reported to pool.hashvault[.]pro. Attackers fingerprinted the host and killed competing miners first. External researchers cited by Wiz and The Hacker News link this chain to Qilin ransomware operators, which means the miner may be the least of it: The Hacker News notes the same campaign harvested database contents for provider keys.

The credential theft was AI-specific. Wiz saw a one-line Python invocation that imported LiteLLM's own proxy module and read the master key out of the loaded process state. A LiteLLM proxy typically holds the upstream keys for every model provider an organization uses, plus whatever cloud IAM role the container runs under, so one memory read can yield OpenAI, Anthropic, Azure and Gemini credentials in a single step. Wiz also logged default-credential checks against `/chat/completions` using the documentation example key `sk-1234`, and blind prompt-injection attempts against other frameworks that used DNS callbacks to an out-of-band domain to confirm execution when no output was visible.

The interpretive point is Wiz's own: attackers are adapting tradecraft to AI infrastructure rather than scanning it as another web application. An LLM gatewayLLM Gateway🛡️A reverse proxy that sits between applications and model providers, holding the real provider API keys, issuing virtual keys to applications, and enforcing budgets, routing and logging. It is a credential concentrator: compromising one gateway can expose every provider relationship an organization has. is a credential concentrator with a tool-execution surface bolted on. That combination is why a bypass on the MCP route is worse than its 8.8 score suggests.

Immediate Actions

  • Inventory every LiteLLM instance, including developer laptops and CI runners, and record the version. Anything below 1.84.0 is vulnerable to this bug; anything from 1.74.2 to 1.83.6 is also vulnerable to the RCE. The `litellm` container image for 1.84.0 is signed with Cosign, and the release notes include the verification command.
  • Upgrade to 1.84.0 or later. The release is marked as containing breaking changes, so test it, but do not let the test cycle push the upgrade past September 16. The GitHub advisory's interim workaround is to disable MCP routes or block `/mcp/` and related MCP paths at the reverse proxy until you can patchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program..
  • Assume compromise for any instance that was internet-reachable below 1.84.0. Rotate `LITELLM_MASTER_KEY`, every virtual key, every upstream provider key the proxy held, and the database credentials. Rebuild the container from a verified image rather than patching in place. The hunting steps in How to Hunt for Forged Admin Tokens and Backdoor Accounts apply almost unchanged.
  • Hunt for the Wiz indicators: outbound connections to 185.62.1[.]8, 185.84.98[.]85, 94.26.106[.]29, pool.hashvault[.]pro or crazyeltonproxy[.]top; hidden directories under `/tmp/.dbus-cache/` or `/app/data/.claude/`; a shell or Python process spawned as a child of the LiteLLM server; and DNS queries to oast.fun subdomains.
  • Check `/config/update` access logs for non-admin callers and review which MCP servers and tools the gateway exposes. If a tool can write to a ticketing system, a repository or a cloud account, the bypass gave anonymous callers that write access. A full lockdown sequence is in How to Lock Down a Self-Hosted LLM Gateway.

Long-Term Outlook

The September 2 KEV batch added seven CVEs. Three of them, LiteLLM, Starlette and Kestra, are components of self-hosted automation and AI stacks that were adopted quickly by engineering teams and have not yet been pulled into the patch discipline that surrounds firewalls and mail servers. Wiz's 2026 cloud data, quoted in coverage of the honeypot study, says 90 percent of cloud environments run self-hosted AI software. That is a large, young, credential-rich attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. with a patch cadence measured in days.

Two shifts follow. First, LLM gateways belong in the same tier as identity providers and VPN concentrators: owned, inventoried, egress-filtered, and patched on a KEV timeline rather than a sprint timeline. The argument for that is laid out in Treating AI Infrastructure as Privileged Infrastructure. Second, the fallback pattern that caused this bug, where a failed check degrades to an anonymous identity so that some other layer can decide, will keep appearing in fast-moving projects that add authentication modes faster than they add tests. The fix commit changed two files and added 349 lines against 25 removed, which is the footprint of a fix that had to add the checks and the tests that were never there.

Sources

  • CISA Known Exploited Vulnerabilities feed (catalog version 2026.09.02): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
  • GitHub advisory GHSA-7488-6r32-c95q (BerriAI/litellm): https://github.com/BerriAI/litellm/security/advisories/GHSA-7488-6r32-c95q
  • Fix commit 73869f0 (PR #26463): https://github.com/BerriAI/litellm/commit/73869f0faf7d11ee21adcb5f91b8c33a340b6c2c
  • LiteLLM v1.84.0 release: https://github.com/BerriAI/litellm/releases/tag/v1.84.0
  • Wiz Threat Research, Attacks on AI Infrastructure: 90-Day Honeypot Telemetry: https://www.wiz.io/blog/ai-infrastructure-honeypot
  • The Hacker News, CISA adds seven exploited flaws: https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html
  • aicybr, LiteLLM CVE-2026-35029 and CVE-2026-59822: https://aicybr.com/blog/litellm-cve-2026-35029-admin-api-takeover
  • Cloud Security Alliance research note on CVE-2026-42271: https://labs.cloudsecurityalliance.org/research/csa-research-note-litellm-cve-2026-42271-ai-gateway-exploita/
  • GitLab advisory database, CVE-2026-59822: https://advisories.gitlab.com/pypi/litellm/CVE-2026-59822/
  • Wiz, TeamPCP trojanizes LiteLLM on PyPI: https://www.wiz.io/blog/threes-a-crowd-teampcp-trojanizes-litellm-in-continuation-of-campaign
  • eSecurity Planet, Wiz finds active LiteLLM and MCP attacks: https://www.esecurityplanet.com/news/news-litellm-mcp-server-attacks/
  • GBHackers, attackers exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. MCP RCE, blind prompt injectionPrompt Injection🛡️An attack that embeds instructions in content a language model will process, so the model takes actions the operator did not intend. In blind prompt injection the attacker cannot see the output and instead confirms execution through a side channel such as a DNS callback to a domain they control. and memory credential theft: https://gbhackers.com/mcp-rce-exploitation/
  • LiteLLM documentation, MCP OAuth: https://docs.litellm.ai/docs/mcp_oauth
← Back to All News