Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise

What it is

Wiz's writeup of an attack chain against LiteLLM, the open-source LLM gateway present in ~one-third of cloud environments. Three CVEs plus two unfixed-by-design issues: MCP auth bypass (CVE-2026-59822, in CISA KEV, exploited in the wild), custom-code-guardrail RCE (CVE-2026-59821), and a config-endpoint authorization gap (CVE-2026-35029, unrelated to Wiz's research). The summary has the shape; what it omits is the version boundaries, the JWT-forgery angle, and a chain constraint that changes how you triage.

Key mechanisms the summary underspecifies

• Master key = JWT signing secret. The master key is also the HS256 secret for session JWTs. If it's left at the default sk-1234, anyone can forge arbitrary user sessions — not just authenticate. As of publication the Docker Compose / pip install default is still sk-1234.
• Unauthenticated-admin-by-default (no CVE; fixed in PR #22095). Pre-patch, when no master key was set, every request got the PROXY_ADMIN role — not merely "unauthenticated access." Default role changed to INTERNAL_USER.
• IMDSv2 bypass detail. The pass-through feature forwards any header prefixed x-pass- with the prefix stripped, so x-pass-X-aws-ec2-metadata-token-ttl-seconds reaches IMDS as a valid token request — defeating IMDSv2.

The chain constraint that matters for triage

The MCP auth bypass does not chain into the RCE. The MCP session only grants MCP-server tool access. The guardrail RCE requires admin, reachable via default/missing master key — a separate precondition. Don't assume KEV-listed CVE-2026-59822 alone gets an attacker to RCE.

Preconditions / Affected

• Guardrail RCE (CVE-2026-59821): LiteLLM before v1.82.0 + admin access (or default/missing key). After v1.82.0 the sandbox is enforced on registration and endpoints are admin-gated; abuse only yields sandboxed execution.
• MCP bypass (CVE-2026-59822): fixed v1.84.0. Single request with Authorization: Bearer a establishes a session.
• Config endpoint (CVE-2026-35029): fixed v1.83.0; before it, any authenticated user (not just admin) could add pass-through routes.
• Scan (Feb 2026): 3,074 instances, 294 (9.6%) accepted sk-1234, of which 191 (6.2%) had no auth at all.

What to do

• Set a strong, unique master key — not sk-1234.
• Review guardrails for unexpected entries and restart the process to clear in-memory code.
• Audit pass-through endpoints and restrict container network egress.
• Apply least-privilege IAM (IRSA or equivalent) to the LiteLLM service account.

flowchart TD
  A[Default/missing master key] --> B[Forge admin JWT]
  A --> C[Unauth admin, pre-patch]
  B --> D[Guardrail RCE, <v1.82.0]
  C --> D
  B --> E[Pass-through to IMDS, IAM theft]
  F[Any Bearer token] --> G[MCP session, CVE-2026-59822]
  G -. no path .-> D

Caveats

The pass-through IMDS technique and MCP allow_all_keys exposure are considered working-as-intended (admins trusted), so they remain abusable post-auth and won't be patched. An August 2026 rescan found 85,000+ instances, but most appear to be honeypots or test deployments.