Nearly 1 in 10 Public LiteLLM Gateways Still Accept the Example "sk-1234" Admin Key

A gateway sitting in front of every model an organization pays for is a strange place to leave the setup-guide password in production. But that's what Wiz Research found when it scanned roughly 3,000 internet-facing LiteLLM deployments in February 2026.[1]

What Wiz actually found

LiteLLM is an open-source AI gateway. Companies put it between their applications and the model providers they pay for — OpenAI, Anthropic, Bedrock, Vertex AI, and dozens of others. It centralizes API keys, enforces spend limits, and increasingly connects to internal tools through the Model Context Protocol.[1] According to Wiz's own data, roughly a third of cloud environments run it somewhere.[1]

Of the 3,074 public instances Wiz found on Shodan, 294 accepted sk-1234[1] — the example master key that appears throughout LiteLLM's own quickstart docs, Docker Compose examples, and tutorials. Of those 294, 191 had no authentication configured at all, meaning they would have accepted any key, valid or not.[1]

That's 9.6% of everything Wiz could see from the outside. A second scan in August 2026 turned up more than 85,000 instances, but Wiz says most of those look like honeypots or test systems, so the two numbers aren't directly comparable — there's no reliable current figure for how many production gateways still ship the default.[1] As of September 9, the current LiteLLM setup guide still uses sk-1234 as its example value, with a comment telling operators to replace it.

Why one key controls this much

The master key does two jobs, and that's the actual design problem. It's the admin credential, and it's also the switch that turns authentication on in the first place. Before version 1.82.0-stable, a gateway started with no master key set granted every incoming request full PROXY_ADMIN rights — not just unauthenticated access, but unauthenticated admin access.[1]

Hold that key — default or otherwise — and you can read every provider's API key stored on the gateway, watch every prompt and response passing through it, and reach whatever internal tools it's connected to via MCP.[1] Wiz's tests went a step further and used pass-through routes to reach the cloud IAM credentials of the machine the gateway runs on.[1] Stolen provider keys alone are enough for LLMjacking — running model workloads on someone else's bill, an abuse Wiz notes has historically caused real financial damage[1] to affected organizations.

The MCP endpoint's own authentication problem — CVE-2026-59822

Separate from the default-key issue, LiteLLM's MCP endpoint runs its own authentication handler, distinct from the gateway's main auth path. It was built to support two kinds of caller: LiteLLM API key holders, and users authenticating through an upstream OAuth2 provider like GitHub. If a bearer token isn't a valid LiteLLM key, the logic is supposed to pass it through as an OAuth2 token instead.[1]

The fallback didn't distinguish "this is a legitimate upstream token" from "this is garbage." When key validation failed with a 401, the handler caught that exception and quietly returned an empty but valid auth object rather than rejecting the request.[1] Wiz demonstrated that an Authorization: Bearer a header — a single character — was enough to open a fully authenticated MCP session.[1] That's CVE-2026-59822, rated 8.8 on the CVSS scale, affecting every version before 1.84.0.[2]

What an attacker reaches through that bypass depends entirely on which MCP servers an organization has connected and how they're scoped. LiteLLM's own documentation recommends an allow_all_keys setting for "low-risk utilities" — but Wiz points out that organizations running LiteLLM internally often connect MCP to Jira, Slack, internal databases, and CI/CD pipelines, on the assumption that network-level trust is enough.[1] The bypass removes that assumption without removing the trust.

A disputed severity: the guardrail code execution flaw

The one code-execution flaw in Wiz's report is CVE-2026-59821[2], and it's worth being precise about a real disagreement here rather than picking whichever number sounds worse. Wiz calls it post-authentication root-level code execution and published a test returning uid=0(root) inside the gateway container.[1] LiteLLM's own advisory for the same CVE rates it Low — 2.1 on CVSS — describing it as a flaw that requires an already high-privilege account to trigger.[2] Both descriptions are technically about the same underlying bug; they just weight the "requires admin" precondition very differently in scoring it.

LiteLLM's guardrails feature lets administrators define Python-like checks that run on every inference request. The web UI's "Run Test" button sandboxes that code — it strips __builtins__ and blocks patterns like import, os, and subprocess before executing anything.[1] The actual registration endpoint, POST /guardrails, didn't apply either protection before the fix. Code submitted there ran through a bare exec(compile(...)) with full standard-library access, and it executed immediately at registration time — before any chat request had to occur.[1]

Two things matter for how bad this actually is in practice. First, exploiting it requires admin access — meaning either a stolen or default master key, or the auth-bypass conditions described above. Second, LiteLLM's fix (shipped in v1.82.0-stable, tracked through PR #22095) closed both gaps: the registration endpoint now enforces the same sandbox as the test button, and both guardrail CRUD endpoints now require the PROXY_ADMIN role explicitly, regardless of whether authentication is otherwise configured.[1] Wiz notes explicitly that its MCP auth-bypass finding does not chain into this RCE — the two are separate paths that happen to share a root cause: trust placed in the master key.[1]

A related flaw, CVE-2026-40217[2], covers a narrower window — versions 1.81.8 up to but not including 1.83.10 — where the guardrail sandbox itself could reportedly be escaped using bytecode techniques, again requiring proxy-admin credentials to reach.[2]

How the master key reaches cloud credentials

Even without any code-execution bug, Wiz found that an admin-level master key alone gives access to more than most people would expect. LiteLLM lets administrators create pass-through endpoints — proxy routes that forward requests to any URL the admin specifies, with no validation against private address ranges, localhost, or cloud metadata addresses.[1] Point one at 169.254.169.254, the AWS instance metadata service, and the response comes back with the IAM credentials of the role attached to that workload.[1]

Switching to IMDSv2 doesn't close this off. LiteLLM forwards any header sent with an x-pass- prefix to the target URL with the prefix stripped, which is enough to supply the token-request header IMDSv2 requires.[1] Wiz is direct about the caveat here: this is a demonstration against Wiz's own test environment, not a documented real-world compromise, and it requires admin access as a precondition. LiteLLM treats the feature as working as intended under a threat model where admins are inherently trusted — it has no CVE and no planned fix.[1] The project's published security policy lists setup mistakes like a missing master key as explicitly out of scope for vulnerability reports.[2]

What's actually being exploited, and what isn't

It's worth separating the findings above — which describe what's possible, largely demonstrated in test conditions — from a different set of older LiteLLM flaws with confirmed in-the-wild activity, because they're easy to conflate.

CISA added CVE-2026-59822[2] — the MCP auth bypass described above — to its Known Exploited Vulnerabilities catalog on September 2, 2026, with a CVSS score of 8.8 and a September 16 remediation deadline for federal civilian agencies.[2] Wiz observed exploitation attempts against its own honeypots starting July 7, using single-character bearer tokens to probe model-listing endpoints — but describes no broader observed use beyond that probing.[1] As Wiz puts it, that flaw "only allows MCP server access"; what an attacker can actually do with it depends entirely on what tool servers are connected.[1]

The flaw attackers have actually used to run code is a different one: CVE-2026-42271[3], CVSS 8.7, which let any authenticated user run commands on the host through two MCP test endpoints. Horizon3.ai reported in June that it could be chained with a Starlette request-smuggling bug, CVE-2026-48710, to skip the authentication requirement entirely.[3] CISA added this one to KEV back in June, citing confirmed active exploitation.[4] Wiz's honeypots recorded it being used to install a cryptocurrency miner.[1]

Microsoft published a case in August describing attackers who ran commands inside a live LiteLLM gateway process, pulled the master key and provider keys out of the container's environment, and used a harvested database connection string to reach the underlying PostgreSQL instance and copy records from LiteLLM's model and virtual-key tables. Microsoft assessed with high confidence that the entry point matched the CVE-2026-42271 and CVE-2026-48710 chain, not the MCP auth bypass or the guardrail RCE covered above.

What to actually do

Upgrading to LiteLLM 1.84.0 or later clears every flaw discussed here — it sits above the fixed version for all of them. If an immediate upgrade isn't realistic, the individual mitigations still hold, starting with the one that costs nothing: rotate the master key. That alone breaks every attack path in this article that depends on holding sk-1234, no upgrade required.

Flaw	What it allows	Affected versions	Fixed in
CVE-2026-59822 — MCP auth bypass	Authenticated MCP session from any bearer token	Before 1.84.0	1.84.0
CVE-2026-42271 — MCP test endpoint command execution	Any authenticated user runs host commands	1.74.2 up to, not including, 1.83.7	1.83.7
CVE-2026-59821 — guardrail check bypass	Code execution inside the container	Before 1.82.0-stable	1.82.0-stable
CVE-2026-40217 — guardrail sandbox escape	Code execution as root in the default image	1.81.8 up to, not including, 1.83.10	1.83.10

• Change the master key from sk-1234 to a long random value. Check first whether a separate salt key is set — the rotation procedure differs, and using the wrong one can leave stored credentials unreadable.
• Upgrade to 1.84.0 or later where possible.
• If you can't upgrade yet, block /mcp/ and the MCP test endpoints, and restrict guardrail creation and update endpoints to admins only, at your reverse proxy.
• Review pass-through endpoints, restrict the container's outbound network access, and scope the workload's cloud IAM role as narrowly as it can function with.
• If you suspect prior access, review the guardrails list for entries you didn't create, restart the process to clear anything held in memory, then rotate provider keys, the master key, and database credentials. Upgrading alone removes neither a guardrail an attacker registered nor a persistence mechanism like an added SSH key.

There's no patch for the pass-through route to instance metadata, because LiteLLM doesn't treat it as a flaw. Outbound network limits and narrow IAM roles are the only controls available for that one.

Security takeaway

None of the individual pieces here are exotic. A default password left in place, an error handler that fails open instead of closed, a feature that trusts whoever holds one credential — these are old, familiar categories of mistake. What's changed is what sits behind them. A LiteLLM gateway isn't just an app anymore; it's frequently the one place holding every AI provider's keys, every prompt passing through an organization, and a live connection into whatever internal systems someone decided to wire up through MCP. Wiz's framing is blunt but fair: treat these gateways as Tier-0 secrets stores, not developer conveniences, and the default-credential problem stops being a footnote.

Sources & References

1. Wiz Research (Amitai Cohen, Yaara Shriki) — "Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise" — September 9, 2026 — View source
2. The Hacker News (Swati Khandelwal) — "Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example 'sk-1234' Admin Key" — September 10, 2026 — View source
3. The Hacker News — "LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE" — June 9, 2026 — View source
4. Help Net Security — "LiteLLM vulnerability under active attack, CISA warns (CVE-2026-42271)" — View source
5. The Hacker News — "CISA Adds Seven Exploited Flaws as Known" (September 2, 2026 KEV batch) — View source

Disclaimer: CVE-2026-59821's severity is characterized differently by Wiz Research (post-auth root RCE) and by LiteLLM's own advisory (Low, 2.1 CVSS, requiring high-privilege access). Both characterizations are presented above rather than resolved in favor of either.