Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example "sk-1234" Admin Key

Nearly one in ten of the internet-facing LiteLLM servers that Wiz Research scanned in February accepted sk-1234, the example admin key in LiteLLM's own setup guide.

LiteLLM is an open-source AI gateway, the software a company puts between its applications and the model providers it pays for. That key is the gateway's administrator credential.

Anyone who holds it can read every model provider's API key stored on the server. In Wiz's tests, it also reached the cloud IAM credentials of the machine the gateway runs on.

Changing the key needs no upgrade, and it closes every path in Wiz's report that depends on holding it.

Where the Number Comes From

Wiz ran one scan. It found 3,074 LiteLLM gateways on Shodan in February, and 294 of them accepted the key.

In 191 of those 294, no key was set at all, so they would have accepted anything. The rest had the setup guide's value left in place.

A second scan in August found more than 85,000 instances, but Wiz says most of them appear to be honeypots or test systems, so the two counts cannot be compared. There is no current figure.

As of September 9, LiteLLM's setup guide still uses sk-1234, above a comment telling operators to replace it with a long random value before any real use.

Why One Key Matters This Much

The master key does two jobs at once, and that is what makes a default value serious. It is the admin credential and the switch that enables authentication.

Before version 1.82.0-stable, a gateway that started without a master key granted every incoming request full admin rights.

An admin on one of these servers has a lot in reach. The gateway can hold an API key for every provider it routes to, see every prompt and reply passing through, and connect to internal tools via the Model Context Protocol (MCP).

It also usually runs with the cloud permissions of the workload it is deployed in. Stolen provider keys alone let an attacker run model workloads on the victim's bill, an abuse known as LLMjacking.

How the Key Reaches the Cloud Account

LiteLLM lets an administrator create a pass-through endpoint, a route that forwards requests to any URL the admin chooses.

The target URL is not checked against private address ranges, localhost, or cloud metadata addresses. An admin can therefore point a route at the instance metadata service and read back the IAM credentials it returns.

Switching to IMDSv2 does not stop this. LiteLLM documents that any header sent with an x-pass- prefix is passed to the target with the prefix removed, and Wiz used that to send the headers IMDSv2 requires.

No source reports anyone doing this against a real deployment. It is a demonstration, and it needs admin access first.

Wiz says the feature is arguably working as intended, because LiteLLM's threat model treats administrators as trusted. It has no CVE and no fix.

The project says much the same about the way in. Its published security policy lists attacks that need a setup mistake, such as not setting a master key, as "explicitly not in scope" and not treated as vulnerabilities.

The Guardrail Flaw, and a Disputed Severity

The one code execution flaw in Wiz's report is CVE-2026-59821, and the researchers and the maintainers describe it very differently.

Wiz calls it post-authentication code execution at root level, and shows a test returning uid=0(root) inside the gateway container. LiteLLM's advisory for the same CVE rates it as Low (2.1 on the CVSS scale), describing it as a flaw that requires a high-privilege account.

Both describe the same behavior. Before 1.82.0-stable, the endpoints that create and update custom code guardrails skipped the sandbox and pattern checks the test endpoint applied, so anyone who could reach them could submit Python that ran inside the container.

The advisory adds that a deployment with no master key treated callers as proxy administrators, which is what put those endpoints within reach.

Wiz's report states that after 1.82.0, an attacker with the default key could only run code within a sandbox. LiteLLM's own record does not support that for every release.

A separate advisory published in May, CVE-2026-40217, says that the sandbox could be escaped using bytecode techniques by running code in the proxy process, which the advisory notes runs as root in the default Docker image.

It covers versions from 1.81.8 up to, but not including, 1.83.10, and reaching the endpoint needs a proxy-admin credential. The master key is that credential.

Both flaws Wiz reported were fixed months before its September 9 report, in February and April, and their CVEs were published in July.

Separately: the LiteLLM Flaws Already Being Exploited

These are older issues, and none of them is the route to cloud credentials described above. They are listed here because they affect the same product and are easy to confuse with it.

CISA added one LiteLLM flaw to its Known Exploited Vulnerabilities catalog on September 2. CVE-2026-59822 (CVSS score: 8.8), also found by Wiz, lets an unauthenticated attacker open a valid MCP session using any Bearer token, including one a single character long. Federal civilian agencies have until September 16 to address it.

Wiz saw it used against its own honeypots starting July 7, in requests that carry single-character tokens to probe model listing endpoints. Wiz described no other use of it.

That flaw does not reach the code execution or credential paths above. Wiz states that it "only allows MCP server access". What it can reach depends on which tool servers an organization has connected to.

The LiteLLM flaw attackers have used to run code is a different one. CVE-2026-42271 (CVSS score: 8.7) let any authenticated user run commands on the host through two MCP test endpoints, and Horizon3.ai reported in June that it could be chained with a Starlette host-header flaw, CVE-2026-48710, to do the same with no credentials at all.

Wiz's honeypots recorded that flaw being used to install a cryptocurrency miner.

Microsoft published a case in August in which attackers ran commands inside a LiteLLM gateway process, read the container's environment for the master key, the provider keys, and the database connection string, and then used that string to access the underlying PostgreSQL database and copy records from LiteLLM's model and virtual-key tables.

Microsoft assesses with high confidence that the attackers gained access through the exposed gateway and says the entry point matches the CVE-2026-42271 and CVE-2026-48710 chain. "Treat AI gateways as Tier-0 secrets stores," the company said.

What to Do Now

Upgrading to 1.84.0 or later covers every flaw in the table. The version ranges are as stated in the advisories.

1. Change the master key from sk-1234 to a long random value. This needs no upgrade. Check first whether a separate salt key is set, because the rotation procedure differs and using the wrong one can leave stored credentials unreadable.
2. Upgrade to 1.84.0 or later. That release sits above the fixed version of every flaw in the table.
3. If you cannot upgrade yet, 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.
4. Also block POST /guardrails/test_custom_code, and restrict POST /guardrails and PUT /guardrails/{guardrail_id} to administrators. These are the workarounds in LiteLLM's own advisories.
5. Review the pass-through endpoints on the gateway, restrict the container's outbound network access, and give the workload the narrowest cloud IAM role it can work with.
6. If you think an attacker may have had access, review the guardrails list for entries you did not create and restart the process to clear code held in memory, then rotate the provider keys, the master key and the database credentials. Upgrading removes neither a guardrail an attacker registered nor an SSH key they added.

There is no patch for the pass-through route to instance metadata, because LiteLLM does not treat it as a flaw. Outbound network limits and narrow IAM roles are the only controls available.

No source sets out how to check whether MCP or pass-through routes are enabled on a gateway you have inherited. Microsoft's hunting queries find exploitation, not configuration.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.