Nearly one in ten LiteLLM gateways accepted the manual's own key, sk-1234

In February, researchers at Wiz Research scanned the internet for exposed LiteLLM servers — the popular open-source gateway that companies place between their applications and paid AI-model providers. Of the 3,074 instances found through Shodan, 294 accepted the key sk-1234 — the very sample admin key listed in the project's official installation guide. In 191 cases no master key had been set at all, so the server would have accepted any string; the rest had simply left the value from the manual untouched. As of September 9, the guide still uses sk-1234, though now with a note that it should be replaced with a long random string.

Why one key matters so much

The LiteLLM master key plays two roles at once: it is the administrator's credential and, at the same time, the switch that turns authentication on. Before version 1.82.0-stable, a gateway launched without a master key granted full administrator rights to any incoming request. And an administrator here can do a great deal: read the API keys of every connected provider, see every request and response passing through the gateway, and connect to internal tools via the Model Context Protocol. The stolen provider keys alone make it possible to run workloads on someone else's account — an abuse known as LLMjacking.

What's more, Wiz showed that through the pass-through endpoints feature, which forwards requests to an arbitrary URL, an attacker can reach the cloud machine's metadata service and extract its IAM credentials. No check is made as to whether the addresses belong to internal ranges, and switching to IMDSv2 offers no protection: LiteLLM forwards headers with the x-pass- prefix. The developers consider the feature to be working as intended — their threat model treats administrators as trusted, so there is no CVE or fix for this.

Holes that are already being exploited

Separately, Wiz lists vulnerabilities already being used in real-world attacks. CVE-2026-59822 (CVSS 8.8) lets an unauthenticated attacker open an MCP session with any Bearer token — even a single character long; CISA added it to its catalog of known exploited vulnerabilities, giving U.S. federal agencies until September 16. Another pair, CVE-2026-42271 and CVE-2026-48710, has already been used to install cryptominers. Microsoft described a case in which attackers read a container's environment variables, obtained the master key, the provider keys and the database connection string, and then copied the data out of PostgreSQL. The company's takeaway is terse: “Treat AI gateways as Tier-0 secret stores.”

What to do

The main recommendation is simple and requires no update: replace sk-1234 with a long random string (first checking whether a separate salt key has been set, otherwise you may render stored data unreadable). Updating to 1.84.0 closes all the vulnerabilities listed in the report. Those who cannot update right away are advised to block MCP and test endpoints at the reverse proxy, restrict the container's outbound traffic, and grant the workload minimal IAM permissions.

Source: The Hacker News