LiteLLM can hold keys for multiple model providers, inspect prompts and responses, execute policy code, proxy outbound requests, and connect models to tools. Calling it “developer middleware” does not reduce those privileges. It is a control plane.
Wiz Research found several distinct ways those privileges could be abused. One of them, CVE-2026-59822, is now in CISA’s Known Exploited Vulnerabilities catalog.
TL;DR
- CVE-2026-59822 let an unauthenticated attacker establish a LiteLLM MCP session with an arbitrary Bearer token. It affects versions before 1.84.0.
- CISA added the flaw to KEV on September 2 and set a September 16 federal remediation deadline; Wiz says its honeypot observed exploitation on July 7.
- CVE-2026-59821 allowed privileged custom-guardrail users to execute Python in the proxy environment. The advisory lists 1.82.0-stable as the patched version.
- These are not one automatic exploit chain. MCP access, guardrail RCE, missing or default authentication, and pass-through endpoint abuse have different prerequisites.
- Upgrade to a current stable release, replace default credentials, restrict MCP tools, deny unnecessary egress and metadata access, minimize the workload identity, and investigate exposed instances.
Four Problems, Four Preconditions
1. MCP Authentication Bypass: CVE-2026-59822
LiteLLM’s MCP endpoint accepted two authentication patterns: native LiteLLM keys and OAuth tokens forwarded to an upstream MCP server. Wiz found that when LiteLLM key validation failed with 401 or 403, the fallback could return an empty authentication object instead of rejecting the request.
An arbitrary Bearer value could therefore create an authenticated MCP session. What the attacker could do next depended on the configured MCP servers and tool permissions. A database query tool, source-control integration, filesystem connector, or CI/CD action can turn “MCP access” into access to the connected system.
The GitHub-reviewed advisory rates the flaw high severity, lists versions before 1.84.0 as affected, and recommends blocking /mcp/ and related routes if an immediate upgrade is impossible.
2. Custom Guardrail Code Execution: CVE-2026-59821
LiteLLM lets administrators define custom guardrails that run around inference requests. Wiz found that the production registration path did not apply the same forbidden-pattern checks and stripped-builtins sandbox used by the UI’s “Run Test” path. Submitted Python could execute in the proxy process.
This issue required access to create or update guardrails, so it is not independently an unauthenticated RCE in a correctly authenticated deployment. The dangerous combination was deployment state: before the fix, an instance with no master key could treat unauthenticated callers as proxy administrators, and the guardrail endpoints did not consistently require the admin role.
GitHub lists versions before 1.82.0 as affected and 1.82.0-stable as the patched version. Wiz observed code running as root in its tested container. Whether that reaches the host or cloud depends on container privileges, mounts, network access, and the workload identity.
3. Default or Missing Authentication
In a February 2026 scan, Wiz found 3,074 public LiteLLM instances. Of those, 294—9.6%—accepted the documented example master key sk-1234 or required no authentication; 191 had no authentication at all. That is a measured snapshot of visible instances, not an estimate that 9.6% of every LiteLLM deployment is exposed.
A default master key is an administrative credential and an HS256 session-signing secret. Changing the UI password while leaving that key in place does not close the trust boundary.
4. Pass-Through Endpoints and Cloud Metadata
Administrators can configure LiteLLM pass-through routes to arbitrary target URLs. Wiz showed that a valid administrator could point such a route at the AWS instance metadata service and forward the headers needed for IMDSv2, retrieving credentials available to the workload.
Wiz and LiteLLM treat this administrator capability as intended behavior rather than CVE-2026-59822 or CVE-2026-59821. It remains relevant because an authentication failure or default admin key can hand an attacker that intended capability. IMDSv2 is valuable, but in this specific path it is not a complete control because the proxy can make the token request and forward headers.
Do Not Flatten the Findings into One Magic Chain
Path A: arbitrary Bearer token -> MCP session -> tools allowed to that session
Path B: missing/default admin authentication -> custom guardrail before 1.82.0-stable -> code execution in the LiteLLM workload
Path C: valid or compromised admin -> pass-through route -> internal service or cloud metadata reachable from LiteLLMThis distinction determines both severity and response. A vulnerable /mcp/ endpoint with no connected tools has a different immediate blast radius from one exposing deployment automation. A patched instance using sk-1234 is still compromised by anyone who knows the default. A least-privilege container can contain code execution better than a root container with broad cloud IAM.
Response Plan
| Owner | Action | How to verify it worked |
|---|---|---|
| Platform team | Inventory LiteLLM in Kubernetes, VM services, developer stacks, and shadow deployments. Record version, image digest, exposure, master-key source, enabled MCP servers, guardrails, pass-through routes, mounts, and service identity. | Cloud, container, DNS, load-balancer, and repository inventories reconcile to one owner per instance. Unknown endpoints are isolated. |
| Application owner | Upgrade to a current stable release that includes the fixes. Version 1.84.0 first fixed CVE-2026-59822, and the CVE-2026-59821 advisory lists 1.82.0-stable, but later security advisories exist; do not freeze on either minimum. Pin the artifact and verify its provenance. | The running process reports the approved version and image digest after restart. A negative authentication test rejects an invalid Bearer token. |
| IAM and secrets teams | Replace sk-1234 and any reused master key. If exposure or suspicious access exists, rotate model-provider, database, cloud, OAuth, webhook, and MCP-connected service credentials and revoke derived sessions. | Old keys fail, replacement keys are unique and scoped, and first use matches expected workloads and destinations. |
| MCP owner | Remove unused servers and tools, avoid broad allow_all_keys access for sensitive integrations, separate read from write capabilities, and require per-user or per-team authorization. | An unprivileged test key cannot list or call administrative, filesystem, database-write, source-control-write, or deployment tools. |
| Cloud and network teams | Remove public exposure unless explicitly required. Restrict management routes, deny workload access to cloud metadata where it is unnecessary, allowlist egress destinations, and apply least-privilege cloud IAM. Run the container as non-root without privileged mode or sensitive mounts. | The workload cannot reach metadata or unapproved internal and internet destinations; its cloud identity cannot enumerate or modify unrelated resources. |
| SOC and IR | Review reverse-proxy and LiteLLM logs for /mcp/ sessions using invalid-looking tokens, unexpected tool calls, guardrail creation or updates, pass-through configuration, and access from new sources. Correlate with process execution, DNS, egress, and cloud audit logs. | A controlled test produces linked gateway, workload, network, and cloud events. Suspicious historical activity is scoped before log retention expires. |
Wiz also recommends reviewing guardrails for unexpected entries and restarting the process to clear in-memory state. Preserve relevant logs and configuration first if compromise is suspected. A restart can remove useful volatile evidence and does not revoke a stolen provider or cloud credential.
What Developers and Users Should Expect
Application teams should receive virtual LiteLLM keys scoped to their models, budgets, and functions—not the master key. They should never be asked to paste a master key into a client app, notebook, chat, issue, or repository. Gateway operators should provide a documented endpoint, certificate identity, and credential-delivery path so a lookalike proxy is easier to reject.
MCP tool access deserves the same review as an API role. “Read-only AI” is not read-only if its connected tool can query a production database, write a repository, open an issue that triggers automation, or deploy a workload.
The vulnerability is in an AI gateway. The security lesson is older and broader: when one service can reach every model, tool, secret, and cloud API, authenticate it like a control plane and contain it like a breach boundary.
Related Posts
- MCP Servers Through an Attacker’s Eyes: What Happens When You Plug In Without Thinking - threat modeling tool access behind model integrations.
- Your Local AI Is Listening — And So Is Everyone Else on Your Network - why local and internal exposure still requires authentication.
- SSRF Explained: How Attackers Make Servers Fetch Secrets for Them - the cloud metadata and internal-network mechanics behind unsafe proxying.
- Non-Human Identities: The Attack Surface Your Security Team Isn’t Managing - lifecycle controls for model-provider, workload, and integration credentials.