One in Ten Exposed LiteLLM Gateways Still Use the Demo Admin Key 'sk-1234'

Key points

• Wiz Research scanned internet-facing LiteLLM servers in February and found nearly 10% accepted sk-1234, the demo admin key printed in the project's own setup guide.
• LiteLLM is an open-source AI gateway, the middleware a company puts between its own apps and paid AI providers like OpenAI or Anthropic.
• Anyone holding that admin key can read every request passing through the gateway, including prompts and replies, plus stored API keys for the paid services behind it.
• The problem is a configuration failure, not a software flaw: administrators copied the tutorial and never changed the placeholder.
• Fixing it takes minutes. Detecting whether attackers already found the door is harder.

A striking share of companies running their own AI plumbing forgot to change the locks.

Researchers at Wiz scanned the public internet in February for servers running LiteLLM, a popular open-source AI gateway. A gateway is the software a business slots between its own applications and the outside AI services it pays for. It handles billing and logging so developers don't have to.

Nearly one in ten of the exposed gateways accepted the string sk-1234 as their administrator password. That string is not a guess. It's the example key printed in LiteLLM's own quick-start documentation, meant to be replaced the moment a real deployment goes live.

Many operators never replaced it.

What can someone do with that key?

Quite a lot. The admin key on a LiteLLM gateway is the master credential. Whoever holds it can read every prompt users have sent through the gateway, every reply the AI returned, and the list of paid API keys the gateway uses to reach providers behind the scenes.

In plain terms: an outsider with sk-1234 can read your staff's private conversations with the AI, see any customer data those conversations included, and walk off with the billing credentials for your OpenAI or Anthropic account, then rack up charges until someone notices.

For a hospital piloting an AI note-taker, that exposure could mean patient records. A law firm faces leaking client matters. The range of damage scales with what the organisation fed into the tool.

Wiz Research's findings on AI gateway exposure sit in a pattern we've tracked before: our August story on poisoned LiteLLM packages on PyPI found stolen secrets traced to two malicious releases of the same library, and a follow-up found most damage traced to a separate Trivy scanner compromise rather than LiteLLM itself. The default-credential problem here is distinct from both, but the target is familiar.

How did this happen?

Copy-paste, mostly. The finding, first reported by The Hacker News, points to a familiar pattern: developers follow a tutorial, get the software working and move on before hardening it.

LiteLLM's docs do use sk-1234 as a placeholder and do tell readers to change it. That instruction's easy to miss when a team is racing to ship an internal chatbot. The gateway then gets exposed to the public internet so remote staff can reach it, and the default credential travels with it. Automated scanners sweep the whole internet for exactly this kind of oversight, criminal and defensive alike.

What the numbers look like

What should companies using LiteLLM do now?

Check the admin key today, not next sprint. If your gateway is reachable from the public internet and the admin key is sk-1234, assume someone already tried it. Rotate the admin key, rotate every downstream provider API key stored in the gateway, and pull the last 90 days of provider billing for spend you can't account for.

Then decide whether the gateway needs to face the public internet at all. Most don't. Putting it behind a VPN removes it from the daily scan sweep entirely.

Ordinary customers of companies using LiteLLM have nothing to do here directly. But if you get a breach notice in the coming weeks citing exposed AI logs, this is the shape of incident to expect.