Attackers Are Exploiting LiteLLM, the Gateway That Holds Your Company's AI Keys

One valid API key was enough to run commands on the server that routes your company's AI

LiteLLM is the quiet plumbing of a lot of corporate AI. It is an open-source gateway, a proxy that sits between a company's applications and the various AI models they call, holding the access keys for every one of them. On June 8, 2026, the U.S. Cybersecurity and Infrastructure Security Agency added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog, the list it reserves for bugs attackers are already using. Federal agencies have until June 22 to patch.

The flaw, CVE-2026-42271, carries a severity score of 8.7 out of 10. On its own it lets any logged-in user run commands on the machine LiteLLM runs on. Chained with a second bug, it lets someone with no account at all do the same thing. For a system whose entire job is to hold the keys to your AI, that is close to the worst case.

How the attack works

The weak point was a convenience feature. LiteLLM lets an administrator preview a connection to an MCP server (the connector that lets an AI assistant reach an external tool or data source) before saving it. Two endpoints handled that preview, and they accepted a full server configuration in the request body, including a command to run and its arguments. When the configuration used the stdio option, LiteLLM did exactly what it was asked: it launched the supplied command as a process on its own host, with its own privileges. The trouble is that those endpoints were guarded by nothing more than a valid API key. Any authenticated user, even one holding a low-privilege internal key, could hand LiteLLM a command and have the server execute it. That is command injection, the kind of mistake that turns a helpful test button into a remote shell.

The researchers at Horizon3.ai then removed the one barrier that remained. They chained CVE-2026-42271 with CVE-2026-48710, a separate flaw in Starlette (the web framework many Python services, LiteLLM included, are built on) that lets an attacker slip past a host-header check used for authentication. Combined, the two bugs score a perfect 10.0 and require no credentials at all. The maintainers closed the LiteLLM hole in version 1.83.7 by requiring an administrator role on those endpoints, and Starlette was patched in 1.0.1.

• The vulnerable releases run from 1.74.2 up to, but not including, 1.83.7. Anything older than the fix is exposed.
• A successful break lets an attacker read the model provider credentials and API keys the proxy stores, run arbitrary commands, and move laterally into connected AI infrastructure.
• This is the second LiteLLM bug under active attack in two months. A SQL injection flaw disclosed in April was being exploited within 36 hours of going public.

Why this lands on your security team, not your ML team

CISA does not add a bug to its exploited list on suspicion, so the active-attack label is the concrete consequence already on record, and the chained version hands an unauthenticated stranger the ability to run code and walk off with secrets. What makes this sting is where LiteLLM sits. A gateway like this is attractive precisely because it is central. It concentrates the keys to every model your organization pays for, it is often exposed to the internet so distributed apps can reach it, and it is frequently stood up by a machine-learning team moving fast rather than by the security group that would harden a normal piece of internet-facing software. If your company runs an LLM proxy, it is one of the highest-value targets you own and possibly one of the least watched. The wider pattern is the one worth raising in your next review: AI middleware has become a hunting ground, and the gap between a flaw being disclosed and being exploited is now measured in hours, not weeks. LiteLLM has had two such bugs in two months.

What to do about it

1. Update LiteLLM to 1.83.7 or later and Starlette to 1.0.1 or later. This is the only step that closes the hole rather than narrowing it, because the patch restores the admin-only check those endpoints should always have had.
2. If you cannot patch today, block the two preview endpoints and pull the gateway off the public internet. Blocking POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at your reverse proxy removes the attacker's reach while you schedule the upgrade.
3. Assume the keys are already gone and rotate them. Rotate every model provider credential and secret the proxy held, and review its logs for unusual host headers and unexpected processes, because a stolen key outlives the patch that closed the door behind it.

Bottom line

LiteLLM did what it was built to do, which was run a command an authenticated user handed it. The problem was that it asked for almost nothing before doing so, and that it guards the keys to an organization's entire AI stack. Treat your AI gateway the way you treat any other system that holds production credentials and faces the internet: patch it on the clock, watch it closely, and assume someone is already probing it. You can track the entry in CISA's Known Exploited Vulnerabilities catalog and read the technical detail in the maintainers' LiteLLM security advisory. If the proxy routing your AI were compromised tonight, how long before anyone noticed, and how many keys would you have to rotate?