Default sk-1234 Key Leaves 294 LiteLLM Gateways Open to Provider Keys and Cloud IAM Theft

LiteLLM functions as an open-source proxy between applications and paid model APIs. The master key serves dual roles as both admin credential and auth enablement flag. Before version 1.82.0-stable, absence of any master key granted full admin rights to every request. Wiz's February Shodan scan showed 191 instances with no key set at all, while the remaining 103 retained the documented sk-1234 value. This single credential grants read access to every upstream API key plus the ability to create routes that fetch IMDSv2 credentials.

The project's security policy explicitly excludes misconfigurations such as unchanged defaults from vulnerability treatment. CVE-2026-59821 covers the guardrail endpoint bypass that permitted root code execution inside containers, yet LiteLLM rated the same issue CVSS 2.1 because it requires the admin key first. The pass-through feature's lack of URL filtering or private-range blocks remains unaddressed because the threat model assumes administrators are trusted.

Default keys in setup documentation create persistent exposure across AI infrastructure. Once the key is obtained, attackers can run model workloads at the victim's expense through LLMjacking and pivot into the underlying cloud account. The August scan's higher count was dismissed as mostly honeypots, leaving no reliable current exposure metric.

LiteLLM's setup guide continued using sk-1234 as of September 9 with only a comment advising replacement. No mandatory key generation or IMDS blocking has been added, so the same exposure vector remains available to any operator following the documented installation path.