Nearly 1 in 10 Public LiteLLM Gateways Wiz Scanned Accepted the Docs' Example Master Key, sk-1234

Verdict: if your LiteLLM gateway is reachable from the internet, change its master key today, then upgrade to 1.84.0 or later. The key change is a config edit, not an upgrade, and it "closes every path in Wiz's report that depends on holding it," as The Hacker News puts it. Our directory rates LiteLLM Conditional on exactly this kind of security discipline, and this report is why that condition exists.

What happened

Wiz Research published "Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise" on 9 September 2026.

The 9.6% figure describes the February sample, not today's internet. Read it as the size of the habit, not a current count.

The same report covers separate flaws, each with a fixed release:

Every fixed version in Wiz's table is 1.84.0 or earlier, so 1.84.0 or later covers all three. The Hacker News lists two more, CVE-2026-42271 (MCP command execution, fixed in 1.83.7) and CVE-2026-40217 (sandbox escape, fixed in 1.83.10), which 1.84.0 also covers.

Why it matters

The master key is the whole gateway. "LiteLLM can hold API keys for every configured LLM provider, process every prompt and response that flows through it, and connect to external tools via MCP," Wiz writes. Wiz showed the pass-through feature reaching the AWS metadata service to exfiltrate IAM credentials; The Hacker News summarizes that in Wiz's tests the key "also reached the cloud IAM credentials of the machine the gateway runs on." One leaked gateway key means every provider bill and potentially the host's cloud account.

The default came from the docs. Wiz: "LiteLLM's documentation uses sk-1234 as the example master key in quickstart guides, Docker Compose examples, and configuration tutorials throughout the docs." As of 9 September the setup guide still used it, above a comment telling operators to replace it, The Hacker News reported. By 23 September, LiteLLM's Docker quick start had dropped it and now generates the key with openssl rand -hex 32. A gateway built from the older guide keeps sk-1234 until someone changes it. LiteLLM's security policy lists attacks that need a setup mistake as "explicitly not in scope." Translation: this is your configuration problem, and nobody upstream will fix a deployed gateway for you.

A second, independent warning. Anthropic's September 2026 threat report says "multiple actors were observed compromising AI wrapper services' implementation of LiteLLM" and used prompt injection "to exfiltrate the production API keys." Different attack path, same asset.

What changes for you

1. Replace sk-1234 with a long random master key. No upgrade needed.
2. Upgrade to LiteLLM 1.84.0 or later, which covers every flaw in Wiz's table.
3. Can't upgrade yet? Block /mcp/, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at your reverse proxy or API gateway. Block POST /guardrails/test_custom_code, and restrict POST /guardrails and PUT /guardrails/{guardrail_id} to administrators.
4. Harden the host. Audit pass-through endpoints, restrict container network egress, and give the workload a least-privilege IAM role.
5. If an attacker may have had access, review the guardrails list for entries you did not create, restart the process to clear code held in memory, then rotate the provider keys, the master key and the database credentials.

Weighing whether to self-host a gateway at all? See LiteLLM vs OpenRouter: a gateway you run carries exactly this hardening burden; one you rent does not.

FAQ

Does changing the master key require upgrading LiteLLM? No. It is a configuration change, and it closes every path in Wiz's report that depends on holding the key.

Which LiteLLM version fixes the disclosed flaws? 1.84.0 or later covers every flaw in Wiz's table, including the MCP authentication bypass CVE-2026-59822.

Is 9.6% of all LiteLLM gateways exposed right now? No. That figure comes from Wiz's February 2026 sample of 3,074 instances. The August scan found over 85,000 instances, most of which appear to be honeypots or test deployments.

Will LiteLLM treat the default key as a vulnerability? No. Its security policy lists attacks that need a setup mistake as "explicitly not in scope."