Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example "sk-1234" Admin Key
- ID
- 23091
- Status
- summarized
- Published
- 10 Sep 2026, 3:12 PM
- Fetched
- 10 Sep 2026, 4:56 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 8.5
- Created
- 10 Sep 2026, 4:58 PM
- Tags
- Audience
- developersai_ml_learnersai_agent_userssaas_startup_founders
What happened
Wiz Research found that 294 of 3,074 internet-facing LiteLLM gateways scanned in February accepted 'sk-1234', the example admin key from LiteLLM's own setup guide. 191 of those had no master key set at all, meaning they accepted any credential. The master key is both the admin credential and the authentication switch—before v1.82.0-stable, a gateway with no key granted full admin rights to every request, exposing all stored provider API keys, prompt traffic, MCP tool connections, and cloud IAM credentials via an SSRF flaw in pass-through endpoints.
Why it matters
If you deploy LiteLLM as an AI gateway, check your master key immediately—changing it to a long random value closes every attack path in Wiz's report with no upgrade required. If you're running a version before 1.82.0-stable without a master key set, every incoming request has full admin rights, including the ability to create pass-through endpoints that can hit cloud metadata addresses for IAM credentials.
Discussion angle
LiteLLM is becoming default infrastructure for routing LLM calls, but its setup guide still ships 'sk-1234' as the example key as of September 9—how do we pressure open-source AI tooling projects to stop using exploitable defaults in documentation, and should teams audit their own AI gateway deployments the same way they'd audit a database exposure?