LiteLLM's June 2026 CVE cluster includes unauthenticated RCE, privilege escalation, and SQL injection. Full breakdown of CVEs, IOCs, patches, and mitigations.
LiteLLM, an open-source AI gateway with over 45,000 GitHub stars and 7,600 forks, has accumulated six CVEs in three months. Two landed in CISA's Known Exploited Vulnerabilities catalog. One chain scores a combined CVSS 10.0. Another scores 9.9. And the SQL injection from April was exploited within 36 hours of disclosure.
This is not a run of bad luck. Each new LiteLLM feature surface (MCP server testing, custom code guardrails, API key self-service) became a credential-exfiltration vector because the architecture centralizes every AI provider credential behind a single proxy. The pattern is structural, and patching faster does not change the underlying shape.
Here is what happened, what to look for, and what to do about it.
CISA added CVE-2026-42271 to its Known Exploited Vulnerabilities catalog on June 9, 2026, citing evidence of active exploitation. The flaw is a command injection rated CVSS 8.7, affecting LiteLLM versions >=1.74.2 and <1.83.7.
The vulnerability sits in two MCP server test endpoints: POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list. These endpoints accept a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. When called with a stdio configuration, the endpoints spawn the supplied command as a subprocess on the proxy host with the privileges of the proxy process.
Access to these endpoints was restricted only by a valid proxy API key. Any authenticated user, including privileged internal-user keys, could execute arbitrary commands on the underlying system. That restriction turned out to be even weaker than it sounds.
Horizon3.ai chained CVE-2026-42271 with CVE-2026-48710, a host header validation bypass in Starlette (CVSS 6.5). The combination completely sidesteps authentication and achieves remote code execution against vulnerable LiteLLM deployments. The combined CVSS score: 10.0.
Any LiteLLM deployment whose dependency tree includes Starlette versions ≤1.0.0 is vulnerable. No credentials required. The attack surface is particularly attractive to actors leveraging automated scanning and exploitation tools because unauthenticated access lowers the barrier to mass exploitation.
Successful exploitation of the chain allows attackers to run arbitrary commands on the LiteLLM host, access model provider credentials, siphon API keys and secrets stored by the proxy, move laterally into connected AI infrastructure, and compromise downstream systems integrated with the gateway.
That list matters because of what LiteLLM stores. A single litellm_credentials row often holds an OpenAI organization key, an Anthropic console key with workspace admin rights, and an AWS Bedrock IAM credential. Sysdig described a successful extraction as closer to a cloud-account compromise than a typical web-app SQL injection.
Obsidian Security disclosed a separate vulnerability chain affecting all LiteLLM versions prior to v1.83.14-stable, rated CVSS 9.9. It allows a low-privilege user to escalate to admin and achieve RCE through three linked flaws:
LiteLLM fails to enforce role-based restrictions when a regular user generates a virtual API key. A non-admin user can create a key with allowed_routes: ['/*'], granting access to all API routes including admin-only endpoints.
The /user/update endpoint allows users to modify their own records without restricting which fields can be altered. An attacker sets their user_role to proxy_admin, gaining full administrative access.
The Custom Code Guardrail feature compiles and executes admin-supplied Python code using exec(). Because exec() is invoked without a safe globals dict, Python injects the full builtins module, exposing __import__, open, and eval. An attacker with admin privileges can spawn reverse shells or deploy persistent malware.
Chain these three together and an attacker with any user-level account reaches full server control. The exfiltration surface includes all provider keys (OpenAI, Anthropic, Gemini, Bedrock, Azure), the master key, salt key, database URL, and all prompts and responses including PII. Persistence can be hidden via litellm_settings.callbacks in config.yaml, which is not visible in the admin UI.
In April 2026, CVE-2026-42208 (CVSS 9.3) emerged as an SQL injection affecting LiteLLM versions >=1.81.16 and <1.83.7. A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a parameter. An unauthenticated attacker could send a crafted Authorization header to any LLM API route and reach the vulnerable query through the proxy's error-handling path.
The timeline was brutal. The patch shipped on April 19. The first exploitation attempt was recorded on April 26 at 16:17 UTC, roughly 36 hours after the GitHub advisory was indexed. CISA added CVE-2026-42208 to its KEV catalog on May 8, 2026.
The attackers were precise. They targeted litellm_credentials.credential_values and litellm_config tables, which hold upstream LLM provider keys and proxy runtime environment configuration. No probes were observed against litellm_users or litellm_team. They knew exactly which tables hold secrets.
This came on top of a supply chain attack in March 2026 by the TeamPCP hacking group, which backdoored LiteLLM PyPI versions 1.82.7 and 1.82.8 to steal credentials from downstream users. More detail on that incident is in our LiteLLM supply chain attack breakdown.
Sysdig's assessment: the 36-hour exploit window is consistent with the broader collapse documented by the Zero Day Clock. The advisory and the open-source schema were enough. Exploitation no longer waits for a public PoC.
For the MCP endpoint chain (CVE-2026-42271 + CVE-2026-48710), look for:
/mcp-rest/test/connection and /mcp-rest/test/tools/listFor the privilege escalation chain (CVE-2026-47101 → 47102 → 40217):
proxy_admin rolelitellm_settings.callbacksallowed_routes or unexpected access to admin endpointsFor CVE-2026-42271 and CVE-2026-42208: Update LiteLLM to version 1.83.7 or later and Starlette to version 1.0.1 or later. The patch restricts the MCP test endpoints to the PROXY_ADMIN role.
For the privilege escalation chain: Update to v1.83.14-stable.
If you cannot patch immediately:
POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or API gatewayRotate credentials even after patching. If these endpoints were exposed to the internet at any point during the vulnerability window, assume compromise and rotate.
Every CVE in this cluster targets the same thing: the credentials LiteLLM stores and proxies. The SQL injection went after litellm_credentials.credential_values. The MCP chain gives arbitrary command execution on a host that holds provider keys in memory. The privilege escalation chain exfiltrates all provider keys, the master key, and the database URL.
This is the architectural consequence of routing raw provider credentials through an open-source gateway. Each new feature (MCP testing, custom guardrails, self-service key management) adds another code path that touches those credentials. Each code path is a potential exfiltration vector. The blast radius of a successful extraction is closer to a cloud-account compromise than a typical application vulnerability.
The question is whether the right response is to keep patching each new vector as it appears, or to remove raw credential storage from the gateway entirely. That is the architectural difference between self-hosted proxy gateways and managed alternatives that never hold your provider keys. If you are evaluating your options, we wrote a detailed comparison of LiteLLM alternatives that covers the security model differences.
For a broader view of LLM security risks across the stack, including prompt injection, model poisoning, and MCP-specific threats, see our guides on AI security threats and what works.
The threat landscape for AI infrastructure is expanding. When your gateway is self-hosted, you own every layer of defense: dependency auditing, runtime isolation, patch management, network segmentation, and secrets rotation. Miss one, and you are exposed.
The March supply chain attack demonstrated that even pip install can be a vector. Open-source does not mean secure. It means the attack surface is visible to attackers, too. And when a package has millions of daily downloads, the window between a compromised release and widespread installation can be measured in minutes.
Teams running self-hosted AI gateways without a dedicated security function are taking on significant risk. The dependency chain alone (Python packages, container images, CI/CD integrations) creates dozens of potential entry points. Without proper governance frameworks, these risks compound quickly.
If your team runs LiteLLM or any self-hosted AI gateway, take these steps immediately.
Ensure you are not running versions 1.82.7 or 1.82.8. Update to the latest patched release that addresses CVE-2026-42271 and CVE-2026-48710.
Every API key, cloud credential, SSH key, and Kubernetes secret that was accessible to your LiteLLM environment should be treated as potentially compromised. Rotate them now.
Check for indicators of compromise: the litellm_init.pth file in site-packages, the sysmon.service systemd unit, unexpected privileged pods in your Kubernetes cluster, and outbound HTTPS connections to unfamiliar endpoints.
Check whether LiteLLM appears as a transitive dependency in other packages you use. Even teams who do not directly use LiteLLM could be affected if another dependency pulls it in.
Pin package versions in your requirements files. Never install from floating version specifiers in production.
Use hash verification for all pinned dependencies to ensure the package contents match what you expect.
Monitor for malicious packages using tools like pip-audit or your CI/CD pipeline's dependency scanning.
Restrict outbound network access from your AI gateway containers to only the provider endpoints they need.
The LiteLLM incidents highlight a broader question: is self-hosting your AI gateway worth the security overhead?
Self-hosted gateways require you to manage the entire security stack. You are responsible for dependency vetting, runtime patching, secrets management, network isolation, and incident response. Every unpatched CVE, every unaudited dependency, every misconfigured network rule is your problem.
Managed alternatives eliminate this attack surface. With a managed gateway, you do not install PyPI packages into your infrastructure. You do not manage the dependency chain. You do not patch CVEs.
shim stores provider keys in its managed secret backend in production and never returns stored secrets in plaintext. The local development backend uses Fernet; production key handling is not based on Fernet.
On the data side, shim applies PII placeholder processing before supported provider execution. It removes the need to run a self-hosted proxy package, but it does not replace your own network controls, dependency review, or shadow-AI governance.
AI gateways route every request your application makes to an LLM provider. They hold the keys, literally, to your AI infrastructure. The LiteLLM incidents in 2026 have made the stakes clear: a compromised gateway means compromised credentials, compromised data, and potentially compromised clusters.
Whether you continue self-hosting or move to a managed solution, treat your AI gateway with the same security rigor you would apply to your database or your identity provider. Audit dependencies. Rotate secrets. Restrict network access. And have a plan for when, not if, the next vulnerability drops.
shim is a managed AI gateway, so customers do not install a gateway package into their application dependency chain. shim still maintains and reviews its own service dependencies. It provides PII placeholder processing, managed production secret storage, and durable request metadata without storing raw request or response bodies.
const openai = new OpenAI({
baseURL: "https://api.getshim.tech/v1",
apiKey: process.env.SHIM_API_KEY
})