LiteLLM Vulnerability: 6 CVEs, a Supply Chain Attack, and the Fixes

TL;DR

LiteLLM, the AI gateway proxy used by CrewAI, DSPy, Microsoft GraphRAG, and roughly 97 million monthly PyPI installs, has been hit by six CVEs and a full supply chain compromise since March 2026. The worst chain scores CVSS 10.0 and gives unauthenticated attackers remote code execution on any exposed LiteLLM proxy. CISA added one of the CVEs to its Known Exploited Vulnerabilities catalog on June 8 with a June 22 remediation deadline. If you run LiteLLM, upgrade to v1.83.14+ and rotate every credential the proxy can reach.

What LiteLLM Does and Why You’re Probably Running It

LiteLLM is an open-source Python proxy that gives you a single OpenAI-compatible API in front of 100+ LLM providers: OpenAI, Anthropic, Google, Azure, Bedrock, Cohere, and more. You point your application at the proxy, the proxy routes requests to the right provider, and you get cost tracking, load balancing, rate limiting, and guardrails for free. About 50,300 GitHub stars and 97 million PyPI downloads a month as of June 2026.

I ran a LiteLLM proxy for three months last year to route Claude and GPT calls from a multi-agent pipeline. The setup took about 15 minutes: a Docker container, a YAML config with my API keys, and a litellm --config config.yaml command. That simplicity is exactly the problem. LiteLLM sits between your entire AI stack and every model provider you use. Every API key, every prompt, every response flows through it. When the proxy gets owned, the attacker gets everything — and AI tooling already leaks secrets at twice the rate of manual code.

And in 2026, LiteLLM got owned from every angle.

Every Vulnerability at a Glance

Plus a full supply chain attack on March 24 that injected credential-stealing malware into PyPI packages v1.82.7 and v1.82.8.

CVE-2026-42271: Remote Code Execution via MCP Test Endpoints

This is the one CISA flagged on June 8 with a June 22 remediation deadline.

LiteLLM versions 1.74.2 through 1.83.6 included two MCP server preview endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These accepted a full server configuration (command, arguments, and environment variables for stdio transport) and LiteLLM spawned the supplied command as a subprocess on the host. Any authenticated user with a standard API key could reach them.

That alone scores CVSS 8.8. But Horizon3.ai researchers chained it with CVE-2026-48710, a host header validation bypass in Starlette versions ≤1.0.0. The Starlette bug lets attackers bypass LiteLLM’s authentication layer entirely by sending a malformed Host header. No API key, no login, no prior access needed.

The combined chain scores CVSS 10.0 and gives any internet-connected attacker unauthenticated RCE on the proxy host.

# This is what the exploit looks like (simplified for illustration)
# The attacker sends a crafted Host header to bypass auth,
# then passes arbitrary commands via the MCP test endpoint
curl -X POST https://target-litellm:4000/mcp-rest/test/connection \
  -H "Host: badhost" \
  -H "Content-Type: application/json" \
  -d '{"server_name": "evil", "transport": "stdio",
       "command": "/bin/sh", "args": ["-c", "id; cat /proc/self/environ"]}'

Horizon3.ai validated the full chain on June 1. CISA confirmed active exploitation in the wild.

The Privilege Escalation Chain: Three CVEs, One Path to Root

Obsidian Security disclosed this chain on June 11, and it’s the scarier find because it starts from a default low-privilege account that every LiteLLM deployment has.

Step 1 — CVE-2026-47101 (Auth bypass): A standard internal_user calls /key/generate with allowed_routes: ["/*"]. LiteLLM validates that the user_id matches the caller but never checks what routes are being granted. The user now holds a wildcard API key that bypasses all role-based access controls.

Step 2 — CVE-2026-47102 (Privilege escalation): The wildcard key accesses /user/update. This endpoint verifies identity but has zero field-level authorization. The attacker sets user_role: "proxy_admin" on their own account and becomes a full admin.

Step 3 — CVE-2026-40217 (Sandbox escape to RCE): Admin-level guardrail endpoints accept user-supplied Python code and compile it with exec(). The globals dictionary omits __builtins__, but Python automatically injects the full builtins module when that key is missing. One line gets you shell access:

# The "sandboxed" guardrail code that actually has full system access
__builtins__['__import__']('os').system('cat /etc/shadow')

Obsidian rates the full chain CVSS 9.9. A server takeover exposes every provider key, every stored credential, every prompt and response passing through the gateway. They demonstrated a “man-in-the-gateway” attack that injected fake tool calls into Claude Code responses, causing it to execute attacker-controlled commands while evading auto-mode safety checks.

CVE-2026-42208: SQL Injection in the Auth Layer

Bishop Fox found this one: a pre-authentication SQL injection via the Authorization: Bearer header. Versions 1.81.16 through 1.83.6 build the token verification query with a Python f-string:

# The vulnerable code in litellm/proxy/utils.py
query = f"WHERE v.token = '{token}'"

LiteLLM’s _hash_token_if_needed() only hashes values starting with sk-. Non-prefixed bearer tokens pass straight to the f-string. An attacker can extract the entire LiteLLM_VerificationToken table — all virtual keys, team bindings, spend records — via timing-based blind injection with pg_sleep().

Default deployments run with database superuser privileges, so the blast radius extends to every table in the database. Sysdig observed in-the-wild exploitation within 36 hours of the GitHub advisory going public, with attackers targeting litellm_credentials.credential_values to steal upstream LLM provider keys.

The March Supply Chain Attack

On March 24, a threat actor called TeamPCP published two backdoored versions of LiteLLM (v1.82.7 and v1.82.8) to PyPI.

The attack chain started weeks earlier. TeamPCP exploited a pull_request_target workflow vulnerability in Trivy (the container security scanner), hijacked the aqua-bot GitHub Actions credentials, and used them to compromise Checkmarx KICS GitHub Actions. When LiteLLM’s CI/CD pipeline ran the compromised Trivy scanner during a build, the malicious action extracted LiteLLM’s PYPI_PUBLISH token from the GitHub Actions environment. CI/CD supply chain risks like this are growing across the ecosystem.

The malicious payload installed a .pth file that fired on every Python interpreter startup — no import required. It harvested environment variables, SSH keys, .env files, API tokens, AWS/GCP/Azure credentials, Kubernetes configs, and database credentials. Everything was encrypted with AES-256-CBC and RSA-4096, bundled into a tarball, and exfiltrated to models.litellm[.]cloud. It also deployed persistence via a fake sysmon.service systemd unit and, in Kubernetes environments, spawned privileged pods on every node.

PyPI quarantined the packages within about 3 hours. But Microsoft GraphRAG, Google ADK, DSPy, CrewAI, and OpenHands all pulled the malicious version as a transitive dependency during that window. Datadog Security Labs later linked this to a broader TeamPCP campaign that also hit npm packages and OpenVSX extensions.

How to Check If You’re Affected

Run these checks in order:

# 1. Check your LiteLLM version
pip show litellm | grep Version
# or inside Docker:
docker exec <container> pip show litellm | grep Version

# 2. Check your Starlette version (for the auth bypass chain)
pip show starlette | grep Version

# 3. Check if the vulnerable MCP endpoints exist
curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:4000/mcp-rest/test/connection
# 404 = not vulnerable (endpoint removed). 405 or 200 = vulnerable.

# 4. Check for supply chain attack artifacts
find / -name "litellm_init.pth" 2>/dev/null
ls -la ~/.config/sysmon/sysmon.py 2>/dev/null
systemctl status sysmon.service 2>/dev/null

If your LiteLLM version is below 1.83.14, you’re exposed to at least some of these vulnerabilities. If it’s between 1.82.7 and 1.82.8 and you installed between March 24 10:39 UTC and ~13:38 UTC, you may have the supply chain backdoor.

How to Fix Everything

Upgrade LiteLLM to at least v1.83.14 (v1.89.1 is the latest as of June 16):

# pip upgrade
pip install --upgrade "litellm>=1.83.14"

# Docker — pull the latest stable image
docker pull ghcr.io/berriai/litellm:main-latest

Upgrade Starlette to close the unauthenticated RCE path:

pip install --upgrade "starlette>=1.0.1"

Rotate credentials. If your proxy was ever internet-accessible on a vulnerable version, treat every secret it could reach as compromised:

# Rotate these (at minimum):
# - LITELLM_MASTER_KEY and LITELLM_SALT_KEY
# - DATABASE_URL and database passwords
# - Every LLM provider API key (OpenAI, Anthropic, Google, Azure, Bedrock)
# - MCP and agent OAuth tokens
# - SSH keys and cloud credentials (AWS, GCP, Azure)

# Check your logs for signs of exploitation:
grep -E "/mcp-rest/test/(connection|tools/list)" /var/log/litellm/*.log
grep -E "/user/(update|bulk_update).*user_role" /var/log/litellm/*.log

If you were hit by the supply chain attack, rebuild your containers from scratch. The backdoor persists through restarts via systemd and .pth files.

Can’t upgrade immediately? These temporary mitigations buy time:

# Block the vulnerable endpoints at your reverse proxy (nginx example)
location ~ ^/mcp-rest/test/ {
    deny all;
    return 403;
}

# Block non-standard bearer tokens to mitigate SQL injection
# Only allow tokens matching the sk- prefix pattern

What Went Wrong, and What It Means for Your AI Stack

LiteLLM’s security problems aren’t unusual for a fast-growing open-source project. The f-string SQL query is a rookie mistake, but it’s the kind of mistake that gets shipped when the priority is features, not security audits. The exec() sandbox with missing builtins is a well-known Python gotcha that’s been documented since 2009.

The supply chain attack is worse. TeamPCP didn’t need to find a bug in LiteLLM’s code, and AI-driven vulnerability discovery means the attack surface is only growing. They compromised the security scanner that LiteLLM’s CI pipeline trusted, then used that to steal PyPI publishing credentials. The attack took weeks to set up and targeted LiteLLM specifically because it sits at the chokepoint of thousands of AI deployments.

If you’re running any AI gateway or proxy, the takeaway is straightforward: treat it like you’d treat your database. Don’t expose it to the internet without authentication. Don’t run it as root. Pin your dependency versions (a good package manager helps), verify checksums on deployment, and have a credential rotation plan that doesn’t require a Saturday fire drill.

CrewAI published a removal guide for decoupling from LiteLLM entirely. Whether that’s the right move depends on your threat model. LiteLLM has since engaged Veria Labs for a proxy audit, launched a bug bounty ($500–$3,000), and committed to 5-business-day response times on advisories. The project is taking security more seriously. Whether that’s enough depends on how many more CVEs are sitting in the other 100,000+ lines of Python.

FAQ

What is CVE-2026-42271?

CVE-2026-42271 is a command injection vulnerability in LiteLLM’s MCP REST test endpoints. Two preview endpoints (/mcp-rest/test/connection and /mcp-rest/test/tools/list) accepted full server configurations and spawned the supplied command as a subprocess. When chained with a Starlette host header bypass (CVE-2026-48710), it becomes an unauthenticated remote code execution vulnerability scoring CVSS 10.0.

What versions of LiteLLM are affected?

For the RCE and SQL injection vulnerabilities: versions 1.74.2 through 1.83.6. For the privilege escalation chain: all versions before 1.83.14. The supply chain attack only affected PyPI packages v1.82.7 and v1.82.8, published on March 24 and quarantined within 3 hours.

How to fix LiteLLM vulnerability?

Upgrade to LiteLLM v1.83.14 or later (v1.89.1 is the latest as of June 2026), upgrade Starlette to v1.0.1+, and rotate every credential the proxy had access to: LLM provider keys, database passwords, the master key, SSH keys, and cloud credentials.

Is LiteLLM safe to use in production?

After upgrading to v1.83.14+, the known vulnerabilities are patched. But LiteLLM has accumulated 16 CVEs across 2024–2026, including three Criticals. If you use it in production, run it behind a reverse proxy, restrict network access, disable unused features like Custom Code Guardrails, and monitor the GitHub advisory feed closely.

What happened with the LiteLLM supply chain attack?

On March 24, 2026, a threat actor called TeamPCP published backdoored LiteLLM versions 1.82.7 and 1.82.8 to PyPI. They got there by first compromising Trivy’s GitHub Actions, then using that access to steal LiteLLM’s PyPI publishing credentials from CI/CD. The malicious packages harvested every credential on the host machine and exfiltrated them to an attacker-controlled server. PyPI quarantined them within about 3 hours, but major frameworks like Microsoft GraphRAG and Google ADK pulled the malicious versions as transitive dependencies during that window.

How does the LiteLLM exploit chain work?

Multiple chains exist. The worst (CVSS 10.0) combines a command injection in MCP test endpoints with a Starlette host header bypass for unauthenticated RCE. A separate chain (CVSS 9.9) starts from a low-privilege default account: the attacker creates a wildcard API key via an unchecked allowed_routes field, self-promotes to admin by modifying their own user_role, then executes arbitrary Python through the Custom Code Guardrail’s broken exec() sandbox.

Sources

• Horizon3.ai — CVE-2026-42271 chained with CVE-2026-48710 — original research on the CVSS 10.0 RCE chain
• The Hacker News — LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over — coverage of the Obsidian Security CVSS 9.9 privilege escalation disclosure
• Help Net Security — LiteLLM vulnerability under active attack, CISA warns — CISA KEV announcement
• Bishop Fox / LiteLLM — CVE-2026-42208 SQL Injection — official advisory for the pre-auth SQL injection
• Sysdig — CVE-2026-42208 exploitation analysis — in-the-wild exploitation within 36 hours
• Snyk — How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM — technical breakdown of the supply chain attack
• HeroDevs — The LiteLLM Supply Chain Attack — timeline and impact assessment
• Datadog Security Labs — LiteLLM compromised PyPI TeamPCP campaign — broader TeamPCP campaign analysis
• LiteLLM — Security Hardening April 2026 — official post-incident security improvements

Bottom Line

LiteLLM got hammered from every direction in 2026: supply chain poisoning, unauthenticated RCE, SQL injection in the auth layer, privilege escalation from default accounts. If you’ve been running an internet-exposed proxy on anything older than v1.83.7, assume breach and act accordingly. The CISA deadline is June 22 — five days from now.