Incident Published: Sep 15, 2026

LiteLLM's MCP Gateway Accepted Any Bearer Token, and Its Test Endpoint Ran Attacker Commands

LiteLLM is an open-source AI gateway that fronts more than 100 model providers and stores their API keys; its MCP Gateway brokers agent access to connected tools such as ticketing systems, chat, and databases. Wiz Research found that a failed token validation fell through to an empty authorization object, so any Bearer token opened an authenticated MCP session (CVE-2026-59822). Separately, the MCP connection-test endpoints spawned caller-supplied commands on the proxy host (CVE-2026-42271). CISA lists both as known exploited.

Authentication BypassCommand InjectionIdentity & AccessMCP SecurityAPI Routers
7 applicable AIDEFEND defenses
Source: Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise 
Authors: Amitai Cohen and Yaara Shriki, Wiz Research
Original article: Sep 9, 2026

Threat Analysis

  • One failed check opened the whole tool surface. LiteLLM's MCP authentication handler treated a failed OAuth2 token validation as a fallback instead of a denial, returning an unrestricted empty UserAPIKeyAuth object. Wiz reports that a single-character Bearer token was enough to list and call every configured MCP tool.
  • A configuration preview became remote code execution. The MCP connection-test endpoints accepted a full stdio server configuration, including the command, args, and env fields, then spawned it as a subprocess with the proxy's privileges. Any low-privilege key could reach it, and chaining a Starlette Host header flaw (CVE-2026-48710) removed the key requirement.
  • The gateway is where credentials concentrate. Microsoft observed real intrusions in which attackers read the master key and provider keys out of the proxy process, queried its PostgreSQL tables for issued virtual keys, then installed a miner and SSH persistence.
  • Keep the evidence boundary straight. Wiz's MCP observations come from its own honeypots; Microsoft's come from real customer telemetry. Wiz repeats an unnamed external claim linking the Qilin ransomware group to this chain; no primary source confirms it.

Applicable AIDEFEND Defenses (7)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
All three CVEs carry CISA remediation deadlines, so the decisive action is upgrading LiteLLM to 1.84.0 or later and Starlette to 1.0.1 or later across the running fleet. Build the affected population from the actual deployed image or package digest rather than a repository lockfile, and close each case only after independent readback proves the fixed version is live everywhere.
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
Very High
Wiz found 3,074 internet-facing LiteLLM proxies in a February 2026 scan, of which 294 accepted the documented default key and 191 required no key at all. Probing from an external vantage point with no corporate credentials surfaces the gateway and MCP routes an unauthenticated client can actually reach, then reconciles each one against an owner and an approved exposure state.
AID-H-034.002
MCP Server OAuth Resource Boundary & Delegation Safety
Very High
An MCP endpoint should never convert a failed token validation into an unrestricted session. Validating issuer, audience, resource, expiry, and scope on every request, and rejecting any token not issued for this exact MCP server, turns the OAuth2 fallback path from a bypass into a denial. This is the control that decides whether CVE-2026-59822 is exploitable.
AID-H-034.003
Server-Side Tool Invocation Validation & Object-Level Authorization
Very High
A preview endpoint should not turn a caller-supplied command field into a subprocess on the host. Denying shell and process execution by default on the MCP server, and binding every side-effecting operation to the authenticated principal and an explicit authorization decision, removes the execution primitive that CVE-2026-42271 depended on.
AID-H-004.002
Service & API Authentication
High
LiteLLM still ships with sk-1234 as the documented example master key, and that same value doubles as the signing secret for session tokens, so an unchanged default lets anyone forge sessions for the entire proxy. Issue a unique high-entropy master credential and per-workload keys with recorded scope and expiry, and store only a keyed digest rather than a recoverable copy.
AID-I-002.002
Secure External AI Service Connectivity
High
If the application-layer checks above are bypassed, the attacker still needs to fetch a payload and send data out. Default-deny egress from the gateway workload, with an allowlist limited to the approved model-provider endpoints, blocks the observed miner download and narrows the outbound path used for credential exfiltration.
AID-E-001.001
Root & Long-Lived Credential Object Eviction
High
Once a gateway on an affected version was internet-reachable, treat every credential it held as exposed. Revoke and rotate the master key, every upstream provider API key, the proxy-issued virtual keys in the LiteLLM_VerificationToken table, and the database credential at their authoritative issuers, then verify the old values no longer authenticate anywhere.

What Defenders Should Do Now

  • Inventory every LiteLLM deployment by running image or package digest, upgrade to 1.84.0 or later, and upgrade Starlette to 1.0.1 or later. Until that lands, block /mcp/ and the two MCP test routes at the reverse proxy, as both vendor advisories recommend.
  • Scan your own external surface for exposed LiteLLM and MCP endpoints, and test them unauthenticated and with the sk-1234 default. Anything that answers is in scope for remediation or removal.
  • Replace the default master key with a unique high-entropy value, issue per-team virtual keys with spend limits instead of sharing the master key, and confirm the proxy is not signing session tokens with a published example value.
  • Apply deny-by-default egress from the gateway workload and allowlist only the model-provider endpoints it genuinely needs.
  • For any instance that ran an affected version while reachable, revoke and rotate the master key, provider keys, issued virtual keys, and the database credential, then look for unexpected pass-through endpoints, unfamiliar guardrail entries, added SSH keys, and miner processes.

Conclusion

An AI gateway is an attractive target because it concentrates what an attacker most wants: every upstream provider key, the tool connections behind MCP, and often cloud permissions on the host. Two ordinary implementation mistakes, a token check that failed open and a preview endpoint that executed caller-supplied commands, were enough to reach all of it. AIDEFEND  maps this path to the controls that decide its outcome: fail-closed token validation at the MCP resource boundary, default-deny command execution and object-level authorization inside the server, per-workload credentials instead of a shared default key, and default-deny egress around the gateway.