Wiz Research's February scan found 3,074 internet-facing LiteLLM gateways on Shodan and 294 of them accepted the example administrator key sk-1234.
The sk-1234 master key — what it is and why one key matters
LiteLLM's master key serves as both the administrator credential and the switch that enables authentication. In Wiz's tests, anyone holding that key could read every model-provider API key stored on the gateway and, in many deployments, reach the cloud IAM credentials of the machine the gateway runs on. Before version 1.82.0-stable, a gateway that started without a master key granted every incoming request full admin rights; in 191 of the 294 servers that accepted sk-1234 there was no key set at all, meaning they would have accepted anything.
That breadth of access matters because an administrator on a gateway can see every prompt and reply passing through, access provider keys, and connect to internal tools using the Model Context Protocol (MCP). Stolen provider keys alone allow running model workloads on a victim's account — a misuse the report names LLMjacking — and the gateway often runs with the cloud permissions of its host workload.
How a pass-through endpoint can reach cloud IAM
LiteLLM administrators can create pass-through endpoints that forward requests to arbitrary URLs. The code does not check targets against private address ranges, localhost, or cloud metadata addresses, so an administrator can point a route at the instance metadata service and read returned IAM credentials. Switching to IMDSv2 does not block this: LiteLLM documents that any header sent with an x-pass- prefix is forwarded with the prefix removed, and Wiz demonstrated using that behavior to send IMDSv2 headers.
Wiz noted this as a demonstration and said no source reported it being used against a real deployment; importantly, the project treats administrators as trusted and does not classify the pass-through behavior as a vulnerability. That makes outbound network restrictions and narrow IAM roles the only available controls for this risk, since there is no patch.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleCVE-2026-59821, related guardrail flaws, and observed exploitation
Wiz and the LiteLLM maintainers described a post-authentication code execution flaw, CVE-2026-59821, differently: Wiz termed it post-authentication code execution at root level and showed a test returning uid=0 (root) inside the gateway container; the project's advisory rated it Low (2.1 CVSS), describing it as requiring a high-privilege account. Both accounts agree that, before 1.82.0-stable, endpoints that create or update custom-code guardrails skipped sandbox and pattern checks that other test endpoints applied, so Python submitted to those endpoints could run inside the container.
A related advisory, CVE-2026-40217, showed sandbox escape via bytecode techniques when code runs in the proxy process; that advisory covers versions 1.81.8 up to but not including 1.83.10 and requires a proxy-admin credential — the master key — to reach the endpoint. Both flaws were fixed months before Wiz published its September 9 report: patches landed in February and April, and their CVEs were published in July.
Separately, CISA added CVE-2026-59822 (CVSS 8.8) to its Known Exploited Vulnerabilities catalog on September 2; Wiz saw that flaw used against its honeypots starting July 7 in probes carrying single-character Bearer tokens. That vulnerability "only allows MCP server access," Wiz wrote, and what it reaches depends on connected tool servers. Another exploited flaw, CVE-2026-42271 (CVSS 8.7), let authenticated users run commands via MCP test endpoints and was reported by Horizon3.ai in June to be chainable with Starlette host-header flaw CVE-2026-48710 to achieve host command execution with no credentials; Wiz's honeypots recorded its use to install a cryptocurrency miner.
Microsoft published a case in August in which attackers ran commands inside a LiteLLM gateway process, read the container environment to obtain the master key, provider keys, and a database connection string, and then used that string to access the underlying PostgreSQL instance and copy model and virtual-key records. Microsoft assessed with high confidence that the entry matched the CVE-2026-42271 / CVE-2026-48710 chain and advised: "Treat AI gateways as Tier-0 secrets stores."
Immediate mitigations operators can apply
- Change the master key from sk-1234 to a long random value. This requires no upgrade and, Wiz says, it closes every path in its report that depends on holding that key. Check whether a separate salt key is set first, because the rotation procedure differs and using the wrong one can render stored credentials unreadable.
- Upgrade to LiteLLM 1.84.0 or later; that release sits above the fixed versions for every flaw in the advisories.
- If you cannot upgrade, block /mcp/ and the two MCP test endpoints — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — at your reverse proxy or API gateway. Also block POST /guardrails/test_custom_code and restrict POST /guardrails and PUT /guardrails/{{guardrail_id}} to administrators; these are LiteLLM's documented workarounds.
- Review pass-through endpoints, restrict the container's outbound network access, and assign the narrowest cloud IAM role the workload can use. There is no project patch for the pass-through route to instance metadata.
- If you suspect compromise: review the guardrails list for entries you did not create, restart the process to clear code held in memory, and rotate provider keys, the master key, and database credentials. Upgrading does not remove guardrails an attacker registered or SSH keys they added.
What this means for technologists, federal agencies, and operators
Technologists and security teams: rotate the master key immediately, inspect and restrict pass-through routes and MCP endpoints, and plan an upgrade to 1.84.0 or later. Check for unexpected guardrails and do not assume an upgrade removes artifacts an attacker may have left.
Federal agencies and compliance teams: note that CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on September 2 and gave federal civilian agencies until September 16 to address it; the same vulnerability was seen in probes beginning July 7.
Operators and procurement owners: as of September 9, LiteLLM's setup guide still uses sk-1234 above a comment telling operators to replace it before real use; changing that default requires no software upgrade and, in Wiz's analysis, closes all the paths that depend on holding it.
Wiz's February scan and its August recounting — the February count of 3,074 instances with 294 accepting the example key versus an August scan showing more than 85,000 instances (many appearing to be honeypots or tests) — underline that a single setup mistake can scale into a systemic risk. For now, the fastest, surest step any operator can take is immediate key rotation, tight outbound controls, and, where possible, an upgrade to 1.84.0 or later.
