11 SEP 2026 — Wiz Research scanned 3,074 internet-facing LiteLLM proxies in February and found that 9.6 per cent of them accepted the default master key or required no authentication at all. The default master key is sk-1234, and it is the placeholder printed in LiteLLM's own quickstart.
The finding is old enough to be uncomfortable rather than surprising. The report published this week is worth reading for a disagreement buried in it: LiteLLM scored one of the reported flaws at 2.1, and Wiz scored the same flaw High. The gap between those two numbers is not a quibble about methodology. It is a disagreement about whether the authentication in front of the flaw exists.
What the master key opens
LiteLLM is a proxy. It sits between an application and every model provider that application uses, presenting one OpenAI-compatible endpoint and holding the credentials for everything behind it. That convenience is the value proposition, and the reason a single key is worth so much.
Anyone holding the master key can read every model provider API key stored on the server. In a documented case, an attacker took the master key, the provider keys and the database connection string, then used the connection string to reach PostgreSQL directly and extract model and virtual-key records.
The damage runs in two directions. An attacker can perform LLMjacking, running inference on the victim's account and at the victim's rates until somebody reads a bill. More seriously, they can take the host: cloud IAM credentials available on the machine turn a proxy compromise into a cloud-account compromise, and the proxy is rarely the asset an organisation has hardened.
The disagreement about 2.1
CVE-2026-59821 is remote code execution as root through LiteLLM's custom-code guardrails feature. LiteLLM rated it 2.1, in the Low band. Wiz rated it High.
Both scores are defensible in isolation. The gap between them is the instructive part. LiteLLM's case is that the flaw is post-authentication and the feature is designed to execute operator-supplied code; an authenticated administrator running code on their own proxy is the product working. Wiz's case is that "post-authentication" is a discount applied to a severity score, and a discount is only worth what the authentication is worth.
Set that against 9.6 per cent. On roughly one in ten exposed instances, the authentication in front of this flaw is a string published in the documentation. For those deployments the word "post-authentication" describes a step an attacker completes by reading the quickstart.
This is the part worth carrying away from the report, because it generalises well past LiteLLM. A severity score is a claim about a population. The vendor scores the deployment it designed; the researcher scores the deployments they found. When those diverge as far as 2.1 and High, the operator has to decide which population they are in.
Two more CVEs, and one is being exploited
CVE-2026-59822 is an authentication bypass through the MCP endpoint, where an arbitrary bearer token creates a valid session. It carries CVSS 8.8 and has been added to CISA's Known Exploited Vulnerabilities catalogue, which is a statement that it is being used rather than merely available.
CVE-2026-42271 is rated 8.7 and is also reported as actively exploited. CVE-2026-40217 appears in the same set.
For an operator, the ordering is straightforward and does not depend on resolving the 2.1 argument. Patch the exploited ones first because exploitation is a fact rather than a forecast. Then decide independently whether the post-authentication flaw is post-anything on your deployment.
How a placeholder becomes production
sk-1234 appears in LiteLLM's quickstart guides, Docker Compose examples and configuration tutorials. It is not a backdoor or a hidden default; it is example text where example text belongs.
The danger is that a proxy quickstart succeeds. The command runs, the endpoint answers, the model responds, and the operator moves on to the thing they were actually trying to build. Nothing in that sequence produces an error, and the temporary step never announces itself.
Our own guide to self-hosting LiteLLM with Docker uses a redacted key generated locally and annotated "never reused". Documentation that cannot be pasted into production is the cheapest control available to anyone writing a quickstart, and the pattern costs nothing to adopt.
A caution about the scan numbers
A follow-up Wiz scan in August found more than 85,000 instances, and the majority appear to be honeypots or test deployments. Do not read that as growth. We are not.
It is a useful caution in the other direction too. Internet-wide scan counts measure what answers on a port, and once a technology becomes interesting to researchers, a large share of what answers is researchers. The February figure — 3,074 instances, 9.6 per cent accepting the default — is the more defensible number because it predates that.
What to do this week
If a LiteLLM proxy has ever been reachable from the internet with the default key, treat every provider credential on that machine as disclosed and rotate them, along with any cloud role the host can assume. The master key is the smallest part of what is exposed.
Then take the proxy off the public internet. Almost none of these need to be reachable from anywhere but the application they serve, and the 9.6 per cent figure is a statement about instances that were exposed at all.
View author profile → · Editorial policy
