Researchers scanned internet-facing LiteLLM deployments and found that of 3,074 public instances, 9.6 percent either accepted the default master key or required no authentication at all.

The default master key is sk-1234. It is not a secret anybody guessed. It is the value LiteLLM's own documentation uses as the example, in the quickstart, in the Docker Compose samples, and in configuration tutorials throughout the docs.

Roughly one exposed gateway in ten is running with the placeholder still in place.

What a gateway is holding

The reason this matters more than an ordinary default-credential finding is what sits behind an LLM gateway.

A gateway exists to be the single place your organisation's model traffic passes through. To do that job, it holds the provider credentials — the keys for the model APIs your organisation pays for — so that individual applications do not have to. That is the entire value proposition, and it is also the entire problem.

With master-key access to a LiteLLM instance, an attacker can:

  • Mint unlimited API keys on the instance
  • Read the stored provider credentials for the upstream model APIs
  • Run inference billed to the victim, at whatever volume they like
  • Read spend logs, which describe what the organisation is doing and how much of it
  • Alter or delete model configurations

So it is not one credential. It is the credential that dispenses credentials, plus a metered billing relationship with somebody else's account.

We covered the poisoned LiteLLM releases in August, which reached the same asset by a much harder route. This one requires reading the documentation.

It is not a vulnerability, and that is the point

There is no CVE to apply here, because nothing is broken. The software does exactly what it is configured to do. The documentation is not wrong either — it has to put something in the example, and a memorable placeholder is a reasonable choice for a quickstart whose purpose is to get you to a working instance in five minutes.

The failure is in the seam between those two correct things: a quickstart optimised for speed, and a deployment path where "it works" and "it is finished" look identical from the outside. Nothing in the system tells you the placeholder is still there. The gateway starts, serves traffic, and reports healthy.

This is a design problem with a known answer. Software that ships with a default credential can refuse to start until it is changed, or generate a random one on first run and print it once. Both are common practice. Neither is what happened.

Somebody is already looking

This is not theoretical exposure. Honeypot telemetry collected between February and June 2026 recorded roughly 3,900 requests aimed at LiteLLM administrative APIs, from 73 distinct IP addresses.

That is a modest number in absolute terms and a significant one in shape: it means the class is being swept for, continuously, by more than a handful of parties, months before this research was published.

And the 9.6 percent figure only describes what a search engine for exposed services can see. Instances behind a load balancer, on a non-standard port, or otherwise not indexed are not in the denominator or the numerator. The true count is unknown and is not smaller.

What to do

  • Check your master key right now. If it is sk-1234, you are in the 9.6 percent. This takes one command and no planning.
  • Do not expose the gateway to the internet at all unless you have a specific reason. This is an internal service by function.
  • Rotate every provider credential the instance holds, not just the master key, if it has ever been internet-facing with the default. You cannot tell from the outside whether anyone used it.
  • Read the spend logs before you rotate. Unexplained inference volume is the cheapest evidence available that someone else was there.
  • Treat every AI gateway as a credential store, because that is what it is, and apply whatever controls you apply to your secret manager.

What is not established

  • How many of the 9.6 percent were actually compromised. The scan measured what would answer, not what had been used.
  • The true exposed population. 3,074 is what one index could see.
  • Whether the honeypot traffic and the exposed instances overlap — the scanning and the telemetry are separate datasets.
  • Whether LiteLLM will change the default behaviour, which is the only fix that closes the class rather than the instances.