Nearly One in Ten Exposed LiteLLM Gateways Accepted Default Admin

Nearly one in ten internet-facing LiteLLM gateways accepted the example sk-1234 admin key in a scan by Wiz Research, and that single default credential opens access to stored provider API keys and, in Wiz's tests, to the cloud identity credentials of the machine running the gateway. LiteLLM is an open-source AI gateway, the software a company places between its applications and the model providers it pays for. The master key is the gateway's administrator credential, and anyone who holds it can read every model provider's API key stored on the server.

Wiz Research ran one scan and found 3,074 LiteLLM gateways on Shodan, a search engine for internet-facing systems, in February. Of those, 294 accepted sk-1234. In 191 of those, no key was set at all, so they would have accepted any value, while the rest had the setup guide's example value left in place. A second scan in August located more than 85,000 instances, but Wiz says most appear to be honeypots or test systems, so the two counts cannot be compared and 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 real use.

The reason one key matters so much is that the master key does two jobs at once. It is both 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 within reach: the gateway can hold an API key for every provider it routes to, can see every prompt and reply passing through, and can connect to internal tools via the Model Context Protocol (MCP), the interface that lets the gateway talk to internal services. 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.

Wiz also showed how the key can reach 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, a newer way to request metadata, 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 behavior to send the headers IMDSv2 requires. No source reports anyone doing this against a real deployment. It is a demonstration and needs admin access first. Wiz says the feature is arguably working as intended because LiteLLM's threat model treats administrators as trusted, so it has no CVE and no fix. LiteLLM's published security policy says attacks that need a setup mistake, such as not setting a master key, are explicitly not in scope and not treated as vulnerabilities.

The one code execution flaw in Wiz's report is CVE-2026-59821, and researchers and 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 Low at 2.1 on the CVSS scale, describing 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 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, 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, the main program that handles traffic, 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, which the master key is. Both flaws Wiz reported were fixed months before its September 9 report, in February and April, and their CVEs were published in July.

Separately, older LiteLLM issues are already being exploited. CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on September 2. The flaw, also found by Wiz, has a CVSS score of 8.8 and 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 carrying single-character tokens to probe model listing endpoints, and described no other use. That flaw does not reach the code execution or credential paths above. Wiz states it only allows MCP server access, and what it can reach depends on which tool servers an organization has connected.

The LiteLLM flaw attackers have used to run code is a different one. CVE-2026-42271 has a CVSS score of 8.7 and let any authenticated user 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 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 relational database server 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. The company added, 'Treat AI gateways as Tier-0 secrets stores.'

Upgrading to LiteLLM 1.84.0 or later covers every flaw in the table. CVE-2026-59822 is fixed in 1.84.0. CVE-2026-42271 is fixed in 1.83.7. CVE-2026-59821 is fixed in 1.82.0-stable. CVE-2026-40217 is fixed in 1.83.10, though LiteLLM's advisory text points to 1.83.11. The first practical step is to change the master key from sk-1234 to a long random value. This needs no upgrade and closes every path in Wiz's report that depends on holding the key. Before rotating the key, check whether a separate salt key is set, because the rotation procedure differs and using the wrong one can leave stored credentials unreadable. If you cannot upgrade