LiteLLM's Default Admin Key Exposed

An admin key copied straight from an open-source project's setup instructions is all it takes to reach the credentials of anyone routing AI traffic through it. Wiz Research reported that nearly one in ten internet-facing LiteLLM servers it scanned accepted sk-1234, the placeholder value shown in the gateway's own quick-start documentation.

LiteLLM is an open-source AI gateway that sits between an organization's applications and the model providers it pays for. The master key is the administrator credential for that gateway, and in Wiz's testing it also unlocked the cloud IAM credentials of the machine the software runs on.

A Placeholder Left in Production

Wiz scanned Shodan in February and found 3,074 LiteLLM gateways exposed to the internet. Of those, 294 accepted the example key. In 191 of those cases, no master key had been configured at all, meaning the server would have accepted any value presented to it. The remainder had the setup guide's literal example string still in place.

The guide itself is explicit about the risk. As of September 9, LiteLLM's setup documentation still used sk-1234, printed above a comment instructing operators to replace it with a long random value before any real-world use. That warning has not been enough to stop deployments from going live with the default intact.

A follow-up scan in August turned up more than 85,000 LiteLLM instances, but Wiz cautioned that most appear to be honeypots or test systems, making the two figures incomparable. There is no current count of vulnerable deployments.

Why a Single String Carries So Much Weight

The master key serves two functions simultaneously, which is what makes a default value consequential. It is both the administrative credential and the switch that turns authentication on. Before version 1.82.0-stable, a gateway started without a master key granted every incoming request full administrative rights.

An attacker holding admin access on one of these servers can read the API key for every model provider the gateway routes to, observe every prompt and response passing through it, and reach internal tools connected over the Model Context Protocol (MCP). The gateway typically runs with the cloud permissions of the workload it is deployed in, so those permissions come along for the ride.

Stolen provider keys have a direct financial payoff: an attacker can run model workloads billed to the victim, a practice known as LLMjacking.

How Admin Access Reaches the Cloud Account

LiteLLM allows an administrator to create a pass-through endpoint, a route that forwards requests to any URL the admin specifies. The destination is not validated against private address ranges, localhost, or cloud metadata addresses.

That omission means an admin can point a route at the instance metadata service and read back the IAM credentials it returns. Switching to IMDSv2 does not close the path: LiteLLM documents that any header sent with an x-pass- prefix is forwarded to the target with the prefix stripped, and Wiz used that behavior to supply the headers IMDSv2 requires.

No source reports anyone actually doing this against a live deployment. It remains a demonstration, and it requires admin access as a starting point. Wiz noted the feature is arguably working as intended, because LiteLLM's threat model treats administrators as trusted. There is no CVE for it and no fix.

The project takes a similar position on the broader class of misconfiguration. Its published security policy lists attacks that depend on a setup mistake, such as failing to set a master key, as explicitly out of scope and not treated as vulnerabilities.

A Guardrail Flaw With Two Readings

The one code-execution flaw in Wiz's report is CVE-2026-59821, and the researchers and maintainers describe it in sharply different terms. Wiz characterizes it as post-authentication code execution at root level, and demonstrated a test returning uid=0(root) inside the gateway container. LiteLLM's advisory for the same CVE rates it Low, at 2.1 on the CVSS scale, describing it as a flaw requiring a high-privilege account.

Both descriptions refer to the same behavior. Before 1.82.0-stable, the endpoints that create and update custom code guardrails skipped the sandbox and pattern checks that the test endpoint applied. Anyone able to reach them could submit Python that executed inside the container.

The advisory adds that a deployment with no master key treated callers as proxy administrators, which is what brought those endpoints within reach. Wiz's report states that after 1.82.0, an attacker with the default key could only run code inside a sandbox, but LiteLLM's own record does not support that for every release.

A separate advisory published in May, CVE-2026-40217, says 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 requires 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, with their CVEs published in July.

Older Flaws Already Being Exploited

Several earlier LiteLLM issues are circulating alongside the Wiz findings, and none of them is the route to cloud credentials described above. They matter because they affect the same product and are easy to conflate.

CISA added one LiteLLM flaw to its Known Exploited Vulnerabilities catalog on September 2. CVE-2026-59822, with a CVSS score of 8.8 and 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 the flaw used against its own honeypots starting July 7, in requests carrying single-character tokens to probe model listing endpoints. Wiz described no other use of it. The company states that it "only allows MCP server access" — what that reaches depends on which tool servers an organization has connected.

The flaw attackers have used to run code is a different one. CVE-2026-42271, CVSS 8.7, allowed any authenticated user to run commands on the host through two MCP test endpoints. Horizon3.ai reported in June that it could be chained with a Starlette host-header flaw, CVE-2026-48710, to achieve the same result with no credentials at all. Wiz's honeypots recorded this 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, 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.

— Microsoft

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.

• CVE-2026-59822, MCP authentication bypass: allows an authenticated MCP session from any Bearer token, reaching the MCP tools that instance has configured. Affects versions before 1.84.0; fixed in 1.84.0.
• CVE-2026-42271, MCP test endpoint command execution: allows any authenticated user to run commands on the host. Affects 1.74.2 up to, but not including, 1.83.7; fixed in 1.83.7.
• CVE-2026-59821, custom code guardrail check bypass: allows code execution inside the gateway container. Affects versions before 1.82.0-stable; fixed in 1.82.0-stable.
• CVE-2026-40217, guardrail sandbox escape: allows code execution as root in the default container image. Affects 1.81.8 up to, but not including, 1.83.10; fixed in 1.83.10, though the advisory text says 1.83.11.

Changing the master key from sk-1234 to a long random value requires no upgrade and closes every path in Wiz's report that depends on holding it. Operators should first check whether a separate salt key is set, because the rotation procedure differs and using the wrong one can leave stored credentials unreadable.

Teams that cannot upgrade yet can block /mcp/ and the two MCP test endpoints, POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list, at their reverse proxy or API gateway. They should 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.

Beyond patching, operators are advised to review pass-through endpoints on the gateway, restrict the container's outbound network access, and give the workload the narrowest cloud IAM role it can function with. 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, and 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 available controls.

Why It Matters

The mechanics behind these findings span everything from a default string copied from a setup guide to a disputed severity rating, and the fixes have existed since February and April. What the Wiz scan suggests is that exposure often has less to do with difficult exploitation than with configurations that were never changed after deployment.

For organizations running an AI gateway, this could mean the credentials most worth protecting are the ones already sitting in the configuration file. The master key controls what the gateway can reach, and the pass-through feature extends that reach to the underlying cloud account. Narrowing the workload's IAM role and restricting outbound traffic are the only controls available for a path LiteLLM does not consider a flaw, according to the report.

For the broader market, the pattern across these flaws points to the difficulty of treating an AI gateway as ordinary middleware. Microsoft's assessment, as quoted in the available material, frames these systems as Tier-0 secrets stores — a designation that implies more restrictive handling than many deployments may currently apply.