Default LiteLLM Key Exposes AI Gateway Administration

Wiz Research found that 294 of 3,074 internet-facing LiteLLM gateways identified through Shodan in February accepted sk-1234, the example administrator key shown in LiteLLM’s setup guide. LiteLLM is an open-source AI gateway used between applications and model providers. In 191 of the 294 cases, no master key had been configured, meaning the gateway would accept any value.

The finding matters because the master key is both an administrator credential and the setting that enables authentication. An administrator can access model-provider API keys stored by the gateway, view prompts and responses passing through it, and work with connected Model Context Protocol, or MCP, tools. Wiz also demonstrated that administrator access could be used to obtain cloud IAM credentials available to the workload hosting the gateway.

Default credentials create a broad exposure

Wiz’s February scan is the basis for the nearly one-in-ten figure. A later scan in August identified more than 85,000 instances, but the researchers said most appeared to be honeypots or test systems, making the two totals unsuitable for comparison. As of September 9, the LiteLLM guide still displayed sk-1234 above a note instructing operators to replace it with a long random value before production use.

Before version 1.82.0-stable, starting LiteLLM without a master key gave incoming requests full administrative rights. Provider credentials exposed through such access can be abused to run model workloads at the victim’s expense, a practice known as LLMjacking. The gateway may also run with cloud permissions assigned to its host workload, raising the value of a compromised administration credential.

Pass-through routes and cloud metadata

LiteLLM allows administrators to configure pass-through routes to URLs of their choice. Wiz found that target URLs are not checked against private ranges, localhost or cloud metadata addresses. An administrator could therefore direct a route to an instance metadata service and retrieve the IAM credentials it returns.

Using IMDSv2 alone does not prevent this demonstrated route. LiteLLM documents that headers beginning with x-pass- are forwarded to the target after that prefix is removed, allowing the headers required by IMDSv2 to be sent. Wiz reported this as a demonstration requiring administrator access, not as evidence of exploitation against a real deployment. LiteLLM considers administrators trusted in its threat model and does not classify the pass-through capability as a vulnerability.

Known flaws and remediation steps

Several separate LiteLLM vulnerabilities also affect exposed deployments. CVE-2026-59822 allows an MCP session with any Bearer token on versions before 1.84.0 and has been added to CISA’s Known Exploited Vulnerabilities catalog. CVE-2026-42271 enabled authenticated command execution through MCP test endpoints, while CVE-2026-59821 and CVE-2026-40217 involved custom guardrail code execution in affected versions.

Microsoft described an August incident in which attackers ran commands in a LiteLLM gateway process, extracted the master key, provider keys and database connection string from the container environment, then accessed the underlying PostgreSQL database. Microsoft assessed with high confidence that entry matched a chain involving CVE-2026-42271 and CVE-2026-48710.

Organizations operating LiteLLM should replace sk-1234 with a long random master key, taking account of any separate salt-key rotation procedure, and upgrade to version 1.84.0 or later. Where an upgrade must wait, LiteLLM advises blocking MCP and specified guardrail endpoints at a reverse proxy, while teams should review pass-through routes, limit container egress and assign the narrowest practical cloud IAM role. These measures reduce the impact of exposed gateways even where an administrator-controlled pass-through route remains by design.