By ByteBot
Two vulnerabilities, chained together, hand an unauthenticated attacker arbitrary code execution on any internet-exposed LiteLLM instance running version 1.74.2 through 1.83.6. No credentials. No interaction. No warning. CISA cataloged both CVEs on September 2nd, and the batch made history: three of seven newly listed exploited flaws target AI infrastructure — the first time AI components have made up nearly half a KEV addition. If you are self-hosting LiteLLM and haven’t patched to 1.84.0, the question isn’t whether you’re exposed. It’s whether anyone has used that exposure yet.
The Chain That Reaches CVSS 10.0
LiteLLM is the de facto AI gateway for Python stacks — a proxy that sits in front of 100-plus LLMs and holds the API keys for all of them. With roughly 96 million monthly PyPI downloads, it’s embedded in enough enterprise and self-hosted AI stacks to make any serious vulnerability a wide-surface event.
CVE-2026-42271 lives in LiteLLM’s MCP test endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These routes were designed to let users preview an MCP server configuration before saving it. The problem is that they accepted the full stdio transport config in the request body — including command, args, and env fields — with no command allowlist and no administrative role gate. Send a crafted body and LiteLLM spawns your process on the host, at full user privileges, outside any sandbox. Standalone CVSS: 8.7.
CVE-2026-48710 is what makes it catastrophic. It’s a Host-header authentication bypass — dubbed BadHost — in the Starlette web framework that LiteLLM runs on. Craft the right Host header and you bypass authentication entirely. Chain the two: skip auth with BadHost, then hit the MCP test endpoint with a malicious command body. Combined CVSS: 10.0. Horizon3.ai published a proof-of-concept demonstrating the full chain in June.
What Attackers Are Already Doing
CISA doesn’t add vulnerabilities to KEV as a precaution. By the time they’re listed, there is confirmed in-the-wild exploitation. For this chain, honeypot infrastructure caught the following:
- XMRig cryptocurrency miners deployed on compromised hosts
- Reverse shells for persistent access
- Harvest of upstream provider API keys — OpenAI, Anthropic, and any other provider LiteLLM was configured to reach
- Exfiltration of model configs and virtual proxy keys
That last point is the one teams underestimate. Miners are noisy — they show up in monitoring. API key exfiltration is silent. Wiz Research walked a chain from the initial auth bypass all the way to full cloud compromise using stolen credentials. Your LiteLLM instance isn’t just an AI proxy — to an attacker, it’s a keyring for your entire LLM infrastructure.
Are You Affected?
Affected versions span 1.74.2 through 1.83.6. LiteLLM 1.83.7 introduced the fix for CVE-2026-42271; 1.84.0 adds the fix for CVE-2026-59822 (a separate MCP auth bypass) and is the current recommended security floor. Check your deployment now.
Self-hosted instances exposed directly to the internet face the highest risk. Deployments behind strict network segmentation have a lower direct exposure, but still need to patch and rotate credentials — if the instance was reachable at any point while running a vulnerable version, assume keys may have been harvested.
One uncomfortable fact: patches existed 56 to 99 days before CISA cataloged these CVEs. Most teams discover exposure after compromise, not before.
Four Things to Do Right Now
- Patch. Upgrade to LiteLLM 1.84.0. It contains breaking changes, so test in staging first. Don’t stop at 1.83.7 — 1.84.0 closes additional CVEs.
- Rotate. Rotate every API key stored in or proxied through LiteLLM while the vulnerable version was network-reachable. Treat them as compromised.
- Restrict. The MCP test endpoints and management interface have no business being publicly accessible. Bind them to a private network. Use a reverse proxy (nginx, Caddy, Envoy) for TLS termination at the edge.
- Harden. Run the proxy as non-root. Drop capabilities. Add Host and Origin allowlisting at the reverse proxy layer. Enable network segmentation and mTLS for internal traffic. A practical hardening checklist is available on DEV Community if you need a starting point.
The Larger Shift
Security teams have spent years hardening application code. The assumption — rarely stated, widely held — was that internal tooling running on private networks didn’t need the same rigor. AI gateways broke that assumption. They’re internal by position but critical by function: they hold credentials, log sensitive prompts, and route to every LLM in the stack. CISA’s September batch didn’t just list two vulnerabilities. It put AI infrastructure in the same threat category as identity providers, CI/CD pipelines, and cloud control planes. That’s a category change, not an incremental alert.
Prompt injection is still a real problem. But the 2026 attack surface is the infrastructure around the models, and LiteLLM’s CVE chain is as clear a signal as any that the security bar needs to catch up.
