LiteLLM Vulnerability: Your AI Gateway Is a Target

CVE-2026-59822, an authentication bypass in LiteLLM’s MCP endpoint, is on CISA’s list of vulnerabilities exploited in the wild. What happened, why it worked, and what it means for the AI plumbing you run.

By Krikor Tengerian · Co-founder, SecuritAI Technologies Ltd. · October 2026

Your team added an AI gateway so every app could share one set of model keys and one set of agent tools. It sits on the network, it works, and nobody has looked at it since. Most companies treat this layer as plumbing. Attackers have started treating it as a door.

If that describes your setup, you are in good company. Gateways like LiteLLM became popular because they make AI easier to run. The LiteLLM vulnerability is a reminder that anything holding the keys to your tools needs the same care as any other internet-facing service.

What the LiteLLM vulnerability is

The US National Vulnerability Database describes LiteLLM as a proxy server, or AI gateway, that calls LLM APIs in OpenAI format. Before version 1.84.0, its MCP Streamable HTTP endpoint let an unauthenticated attacker send a fabricated Authorization header that triggered an OAuth2 passthrough fallback path. That path replaced a failed LiteLLM key check with an empty authentication object, so requests reached MCP tooling without a valid LiteLLM key.

The GitHub advisory GHSA-7488-6r32-c95q spells out the impact: an attacker could list and call the MCP tools configured on the gateway and access the services connected through them. GitHub rates it high severity, with a CVSS v4 base score of 8.8, reachable over the network with no privileges and no user interaction.

Timeline of the LiteLLM vulnerability

• June 30, 2026: the advisory was published in the LiteLLM project on GitHub, with the fix in version 1.84.0.
• July 8, 2026: CVE-2026-59822 was published in the National Vulnerability Database.
• July 22, 2026: GitHub reviewed it and published it to the GitHub Advisory Database.
• September 2, 2026: CISA added it to its Known Exploited Vulnerabilities catalog, based on evidence of active exploitation.

Two months passed between the fix and the exploitation notice. Any gateway that was not updated in that window should be treated as exposed until you have checked it.

Are you affected by the LiteLLM vulnerability?

Three questions settle it for most teams:

1. Do you run LiteLLM anywhere? Check production, staging and any developer machines or containers used for pilots. For a Python install, pip show litellm prints the version.
2. Is the version below 1.84.0? If yes, the LiteLLM vulnerability applies to that install.
3. Are MCP routes enabled and reachable? The exposure is through the MCP endpoint, so a gateway with MCP routes reachable from outside your network is the case to fix first.

If you answer yes to all three, patch now and review the logs before you close the ticket. If you only use a hosted service built on LiteLLM, ask the provider which version they run and when they updated.

Here is the part people get wrong

Teams spend their AI security effort on the model: jailbreaks, prompt injection, what the chatbot might say. The LiteLLM vulnerability had nothing to do with the model. It was an authentication bug in internet-facing software that happens to hold the keys to your AI tools. The model was never asked anything. The attacker walked past it.

That matters for how you budget. Model testing is necessary, but the gateway, the MCP servers and the credentials they hold are where an attacker can skip the model entirely.

Why the fallback path matters

The failure was a fallback that let a request through when the normal check failed. Security people call this failing open. A login check that fails should deny the request, every time, even when a second method of authentication is available.

The MCP project’s own security guidance are blunt on the related point. They call token passthrough, where an MCP server accepts a token without checking that it was issued for that server and passes it to the downstream API, an anti-pattern that the authorization specification forbids. They warn that it lets clients get around rate limits and monitoring, and leaves logs that show the wrong identity. MCP servers must not accept tokens that were not issued for them.

You do not need to read the protocol to act on this. Ask whoever runs your gateway two questions: what happens when a key check fails, and does any route accept a token it did not issue.

What to do about the LiteLLM vulnerability this week

1. Inventory your AI plumbing. List every gateway, proxy and MCP server you run, including the ones a developer set up for a pilot.
2. Patch. If you run LiteLLM, confirm you are on version 1.84.0 or later, as the advisory recommends.
3. If you cannot patch today, follow the advisory’s workaround: disable the MCP routes, or block access to /mcp/ and related endpoints at your reverse proxy or API gateway.
4. Take it off the internet. A gateway that only your apps call does not need to be reachable from everywhere.
5. Limit what the tools can do. Give each MCP tool the smallest access its task needs. The MCP security guidance recommends a minimal starting set of scopes, with more granted only when a privileged action is first attempted.
6. Look back. Review gateway logs for requests to MCP tools that did not carry a valid key, and check the services those tools connect to.
7. Rotate what was exposed. If you find unexplained MCP calls, rotate the credentials of the connected services, not only the gateway keys.

A US catalog, a global priority

CISA’s catalog is written first for US federal agencies, which its directive BOD 26-04 requires to prioritize fixing high-risk vulnerabilities in the catalog. In the same alert, CISA encourages all organizations to prioritize the vulnerabilities in the catalog. Canadian companies run the same open source gateways as everyone else, so the catalog listing is a good reason to move the LiteLLM vulnerability to the top of your list.

Test the agents, not only the model

The OWASP Gen AI Security Project lists this kind of risk as LLM06:2025 Excessive Agency, with three root causes: excessive functionality, excessive permissions and excessive autonomy. An agent that can call tools is only as safe as the weakest path to those tools.

AI red teaming includes agent abuse tests, which try to manipulate tool-using agents into actions they should not take, alongside prompt injection, data exfiltration and system prompt leakage. Run them after every new tool or permission you add, and include the question “what if the gateway’s login fails open”.

Where SecuritAI fits

The SecuritAI AI Firewall sits in front of your model as a proxy and enforces your access rules, including rate limits, allowed countries, time windows and trusted sources. It keeps an exportable audit log, with inspection and log storage in Canada. It is a separate control from your gateway’s own login, which is the point: one bug should not open everything.

To be clear about the limit: a firewall does not patch your gateway. Update LiteLLM first. Then add layers so the next authentication bug, in any component, reaches less.

References

1. NIST National Vulnerability Database, CVE-2026-59822, published July 8, 2026
2. GitHub Advisory Database, LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback (GHSA-7488-6r32-c95q)
3. CISA, CISA Adds Seven Known Exploited Vulnerabilities to Catalog, September 2, 2026
4. Model Context Protocol, MCP security guidance (the specification’s security page)
5. OWASP Gen AI Security Project, LLM06:2025 Excessive Agency
6. LiteLLM on GitHub, Release v1.84.0

← Back to the blog