Wiz: nearly 1 in 10 exposed LiteLLM gateways accept the example admin key sk-1234

On 9 September 2026 Wiz Research published a study of LiteLLM, the open-source AI gateway that sits between applications and the model providers they pay for, and reported that 294 of the 3,074 LiteLLM deployments it could reach on the public internet — 9.6%, nearly one in ten — accepted sk-1234, the example master key printed in the project's own setup documentation, or required no credential at all. That string is not an ordinary API key: in LiteLLM it is both the administrator credential and the switch that turns authentication on, so whoever presents it can read every model provider key stored on the gateway, watch every prompt and completion that passes through it, and reach every tool server connected over the Model Context Protocol. Wiz's co-authors, Amitai Cohen and Yaara Shriki, chained that access to root-level code execution and to the theft of the host's cloud IAM credentials. This account rests on Wiz's report, LiteLLM's own security advisories and the CISA Known Exploited Vulnerabilities listing that followed, and the AI incident archive holds this record alongside its neighbours, each with its own sources, severity and confidence grade.

The publication date is the only date the record carries, and it is a publication date. The scan behind the headline was run in February 2026; the two code flaws Wiz describes had shipped fixes by mid-May at the latest, in releases the project's own records date to March and May; the CVE identifiers were issued in July; and the catalogue listing came in September. Almost everything in the report was already old by the time it was printed, which is a large part of what the report argues.

The 9.6% is one scan, and Wiz says its own August follow-up cannot be compared with it

The measurement is simple and Wiz states its method plainly: 3,074 internet-facing LiteLLM proxies found through Shodan in February 2026, each tested for whether it would authenticate with the documented example key. Of those, 294 did. Within that group, 191 had no master key configured at all and would have accepted any string offered to them; the rest had left the setup guide's placeholder in place. Neither failure mode requires a software bug. Both need only the gateway's address and the value printed in the project's own README.

It is also a single vendor's scan. Wiz's figure has been repeated by the Cloud Security Alliance's AI Safety Initiative on 10 September and by The Hacker News the same day, but both repeat it attributively, and no independent replication of the 3,074 figure was located for this article. Wiz ran a second scan in August 2026 and found more than 85,000 instances, some twenty-seven times the February count. The company says most of those appear to be honeypots or test deployments, and that the two counts cannot be compared. There is no current exposure figure, and any article quoting one is quoting February.

One further number in the report is Wiz's own telemetry rather than a scan: the company says LiteLLM is present in roughly one-third of the cloud environments it observes. That is a vendor's view of its own customer base and is worth holding at arm's length, but it explains why the researchers treated a gateway misconfiguration as a cloud problem rather than an application one.

The master key is both the admin credential and the switch that turns authentication on

LiteLLM's design gives one secret two jobs. The master key authenticates administrative requests, and its presence is what enables authentication at all: with no master key and no JWT or OAuth2 configuration, the proxy runs open and accepts every request. Wiz approached the codebase with Anthropic's Claude Code, looking for features that take user-controlled input and pass it to an execution context, and the authentication handler was one of three surfaces it flagged.

Before v1.82.0-stable the consequence of that second job was worse than an open proxy. Wiz found that when no master key was set, the auth handler assigned the PROXY_ADMIN role to every incoming request, so an unauthenticated caller was not merely admitted but admitted as an administrator. Pull request #22095, cited in the report, changed the default role to INTERNAL_USER and added an admin check to the guardrail endpoints.

Administrative access to a gateway is not a narrow privilege. The instance holds an API key for every provider it routes to, which is what makes it a target for LLMjacking — running model workloads on the victim's bill. It sees the prompts and completions. It connects outward to MCP tool servers, which in an internal deployment are likely to include issue trackers, chat, databases and deployment pipelines.

Wiz also demonstrated a path from that administrative seat to the host's cloud identity. LiteLLM lets an administrator register a pass-through route to any target URL, and the target is not checked against private address ranges, localhost or the cloud metadata address. Pointing a route at the instance metadata service returns the IAM credentials the workload runs under. Switching the metadata service to IMDSv2, which normally defeats this class of request forgery by demanding a session token obtained separately, does not help: LiteLLM forwards any header prefixed x-pass- to the target with the prefix stripped, so the token header can be smuggled through. Wiz says the feature is arguably working as intended under a threat model that trusts administrators, and that it therefore carries no CVE and no fix.

That last paragraph is a demonstration, not an observed attack. The Hacker News, reporting the research on 10 September, states that no source reports anyone doing it against a real deployment, and that it requires admin access first. Wiz's framing is the same: the pass-through is a design property that becomes a vulnerability only when the administrator credential is a string from the documentation.

8.8 and 2.1 are rating the same chain from different starting positions

Two CVEs carry the technical findings, and their published scores could hardly be further apart.

CVE-2026-59822 is the MCP authentication bypass, and LiteLLM's advisory rates it High, 8.8 under CVSS 4.0, with no privileges required, no user interaction and no attack requirements. The MCP endpoint has its own authentication handler, built to accept either a LiteLLM key or an OAuth2 token destined for an upstream tool server. When a token failed LiteLLM's validation, the handler caught the 401 and substituted an empty authentication object instead of rejecting the request. Any Bearer token therefore produced a valid MCP session, including a single character: Wiz's proof of concept sends a one-letter bearer token and receives a session identifier back. The flaw is fixed in 1.84.0.

CVE-2026-59821 is the guardrail flaw, and the same project's advisory rates it Low, 2.1, with high privileges required and attack requirements present. The custom code guardrail feature lets an administrator submit Python that the server compiles and executes. The Web UI's test endpoint validated the code against a forbidden-patterns list and stripped the builtins before running it; the production create and update endpoints did neither. Python repopulates builtins when they are absent, so submitted code reached the standard library. Wiz's proof of concept registers a guardrail that runs a shell command at registration time — before any model request — and returns the command's output as the block reason, which in its test came back as root. The flaw is fixed in v1.82.0-stable.

The two descriptions are compatible, and the reconciling sentence is in the advisory itself: LiteLLM notes that in deployments without a configured master key, callers could be treated as proxy administrators, which is what put the guardrail endpoints within reach. A 2.1 assumes a privileged user. Wiz's chain is what happens when the default key makes every caller privileged. Neither score is wrong about its own starting position; they disagree about how often that position is free.

One caveat attaches to Wiz's claim that after 1.82.0 an attacker holding the default key could only execute code inside a sandbox. The Hacker News points to a separate May 2026 advisory, CVE-2026-40217, which describes escaping that sandbox through bytecode techniques in versions from 1.81.8 up to but not including 1.83.10, inside a proxy process that the advisory says runs as root in the default container image. Reaching that endpoint needs a proxy administrator credential, which is precisely what the master key is.

The 8.8 is not universal either. The Cloud Security Alliance's research note observes that GitLab's advisory lists a base score of 8.2 for the same flaw and declines to adjudicate between the two methodologies, noting only that both sit in the high range. The record's severity of high does not turn on which number is used.

One CVE was exploited in the wild; the default-key exposure has no named victim

CISA added CVE-2026-59822 to the Known Exploited Vulnerabilities catalog on 2 September 2026 and set a remediation deadline of 16 September 2026 for federal civilian agencies; the catalogue entry carries CWE-287 and CWE-306, improper authentication and missing authentication. The Cloud Security Alliance note reports that industry trackers have described it as the first MCP-specific flaw on that list. Wiz has published the exploitation it observed: from 7 July 2026 its honeypots logged requests carrying single-character bearer tokens probing model-listing endpoints, and Wiz describes no other use of the flaw.

Nothing comparable exists for the default key. No victim is named, no gateway is identified as having been taken over through sk-1234, and no telemetry shows the 294 hosts being used. The archive entry records no real harm, which is a statement about evidence rather than about the mechanism: the exposure was measured, not witnessed being used.

Two other items are often filed alongside these and are not the same thing. CVE-2026-42271, command execution through two MCP test endpoints, is the LiteLLM flaw attackers have actually used to run code; Wiz's honeypots recorded it installing a cryptocurrency miner. The August 2026 case Microsoft published, in which an intruder read a gateway container's environment variables, recovered the master key, the provider keys and a database connection string, then copied records from LiteLLM's model and virtual-key tables, illustrates what a compromised gateway is worth rather than a new way in; The Hacker News reports that Microsoft assesses the entry point as the CVE-2026-42271 chain.

The maintainers' position is that a missing master key is a setup mistake, not a vulnerability

LiteLLM's security policy is explicit. It lists among out-of-scope issues "attacks that require a misconfiguration on setup (e.g not setting a master_key on the proxy configuration)", and states that these are explicitly not in scope and are not considered vulnerable. Wiz reaches a compatible conclusion from the other direction when it calls the pass-through behaviour arguably working as intended.

That position has been tested in public. On 15 August 2026 a researcher filed GitHub issue #37054, reporting that a proxy with LITELLM_MASTER_KEY unset authenticates any key value and that the shipped docker-compose file does not set one. The issue was closed 30 minutes later, and the only comment on it is from the same account: it cites the security policy's instruction that reports go through private vulnerability reports rather than public issues, apologises for filing publicly, and says the full report was being submitted through the advisory path instead. No maintainer reply appears on the thread, so the record shows the reporter withdrawing the public report rather than a project response to it. Nothing public records what became of the private submission.

No public statement from BerriAI defending or revising that position on the September report was located for this article. The company's visible response is in its release notes and its configuration files rather than in prose.

The enforcement arrived on 3 October, twenty-four days after the report

The two code flaws were fixed long before the report. Wiz's disclosure timeline records the guardrail code execution reported on 18 February 2026 and fixed on 25 February in v1.82.0, the MCP bypass fixed on 25 April in v1.84.0, exploitation observed on 7 July, the CVE identifiers published on 8 July and the catalogue listing on 2 September. The release artefacts carry later dates than the fixes do: the package index shows v1.82.0 on 1 March 2026 and v1.84.0 on 14 May, which mark when each fix became installable rather than when it landed. Two first-party release records date the same fixes later than that timeline does. The v1.82.0-stable release on GitHub carries 11 March 2026 and the 1.82.0 package on PyPI 1 March; v1.84.0 is dated 14 May 2026 on both. Nothing published explains the gap, and it does not matter to the argument, since every one of those dates falls months before the September report. The two GitHub advisories add a third date still: they were published on 30 June 2026, three weeks before the CVE identifiers Wiz says went out on 8 July.

What none of those releases fixed was the default. Wiz reported that as of 9 September the master key was still set to sk-1234 when installing LiteLLM through Docker Compose or pip install, and The Hacker News confirmed the setup guide still used the value that day. The change came with v1.104.0, uploaded to the Python Package Index on 3 October 2026, whose release notes list it as a breaking change: the proxy now refuses to start with an unset, empty or publicly known master key, naming the source of the bad value in the startup error and printing a command that generates a secure one. A companion entry records a change to stop advertising a publicly known weak master-key value in shipped configs and examples, and the docker-compose file on the project's main branch no longer sets a key at all.

That is the sequence worth keeping. The code was patched in the spring. The value that made those patches insufficient stayed in the installation instructions into October, and only then did the software start refusing it. Nothing in either fix required the other to wait.

What has not changed is the pass-through route to the instance metadata service. It still carries no CVE and no fix, because the project treats administrators as trusted. Wiz's remediation list is therefore mostly operator work: a strong and unique master key, a review of registered guardrails followed by a process restart to clear code held in memory, an audit of pass-through endpoints with restricted container egress, and least-privilege IAM roles. None of those four arrives by upgrading alone.

What the record does not establish

• No independent replication of the 3,074-host scan was located. The 9.6% is Wiz's measurement, and every other account of it repeats the figure attributively.

• No current exposure figure exists. The August follow-up found more than 85,000 instances, which Wiz says are mostly honeypots or test deployments and cannot be compared with February's count.

• No victim. Nothing in the record names a gateway, an operator or a cloud account compromised through the default key, and the exploitation Wiz documents is of the MCP bypass rather than of sk-1234.

• No evidence that the 294 hosts were used. The scan tested whether they would authenticate, which is a weaker claim than showing that anyone did.

• No settled severity for the guardrail flaw. Wiz and the maintainers describe the same behaviour and rate it very differently, and the difference is about the privileges each assumes the attacker already holds.

Wiz is also a cloud security vendor that sells detection for this class of exposure, and the report closes with a section on how its own products identify LiteLLM deployments, vulnerable versions and shadow instances. That is context for reading the remediation section, not a reason to discount a measurement whose technical details the maintainers' own advisories corroborate.

The part of the record that travels beyond LiteLLM is the space between two dates. The vulnerability was closed in the spring. The default that made the vulnerability matter to a stranger was still being printed in the installation instructions in September, and the software only began refusing it in October. The operators who changed the string never had to wait for any of that.