1 in 10 Exposed LiteLLM Gateways Still Use Default Admin Key sk-1234

A Wiz Research investigation has revealed that nearly 10% of internet-facing LiteLLM gateways scanned in February 2026 were still configured with sk-1234, the example admin master key published in the project's own setup documentation. LiteLLM, an open-source AI gateway that sits between enterprise applications and large language model providers, grants holders of this credential unrestricted administrative access over the deployment. Researchers confirmed that the key unlocks every downstream provider API key stored on the server and, through a pass-through routing flaw, can pivot to the cloud IAM credentials of the underlying host instance.

The figures come from a single Shodan scan conducted in February, which identified 3,074 publicly reachable LiteLLM instances. Of those, 294 accepted the sk-1234 value, and in 191 of those cases no master key had been set at all, meaning any arbitrary string would have granted full administrative rights. A follow-up scan in August returned over 85,000 results, but Wiz noted that the surge consisted largely of honeypots and test deployments, rendering the two datasets non-comparable. The setup guide on LiteLLM's documentation site continued to display sk-1234 as of September 9, despite an inline comment instructing operators to replace it before any production use.

The severity stems from the master key serving a dual role: it acts as both the administrator credential and the toggle that enables request authentication. Prior to version 1.82.0-stable, gateways launched without a master key issued full administrative privileges to every incoming request. An attacker holding admin access can exfiltrate API keys for every routed provider, intercept every prompt and response traversing the gateway, and reach internal services via the Model Context Protocol (MCP). The blast radius extends directly to the cloud account. Wiz demonstrated that LiteLLM's pass-through endpoint feature forwards requests to arbitrary URLs without filtering private address ranges, cloud metadata services, or localhost. By leveraging the documented x-pass- header prefix passthrough, an administrator can satisfy IMDSv2 token requirements and retrieve temporary IAM credentials from the instance metadata service, enabling full cloud account takeover. Infrastructure teams should audit exposure with a port scanner to identify unintended LiteLLM instances facing the public internet, and verify credential strength using a password strength checker.

LiteLLM's published security policy treats these vectors as expected behavior, noting that they require a setup mistake or trusted administrator access. No CVE has been issued and no fix is planned. The most effective remediation is immediate: replace sk-1234 with a cryptographically random value, ensure the master key is always set, and upgrade to version 1.82.0-stable or later to close the unauthenticated admin path. Operators should also audit existing pass-through routes and restrict outbound network access from gateway hosts to prevent metadata-service abuse and LLMjacking campaigns that monetize stolen provider keys.