Nearly one in ten exposed LiteLLM gateways still accept the documentation's example admin key
Wiz found 3,074 internet-facing LiteLLM gateways, of which 294 accepted sk-1234, the key printed in the setup docs. In 191 of those no key was set at all, which defaults to full admin: every provider API key, every prompt, and MCP access.
Wiz Research used Shodan to enumerate 3,074 internet-facing LiteLLM gateways and found 294 of them, nearly one in ten, accepting sk-1234, the example master key printed in LiteLLM's own setup documentation. In 191 of those cases no key was configured at all, which the software treats as full administrator access. That access exposes every stored provider API key, every prompt and response passing through the gateway, connections to internal tools over the Model Context Protocol, and, where pass-through endpoints are configured, a path to cloud IAM credentials. Wiz recommends replacing the key with a long random value, which needs no upgrade, then moving to version 1.84.0 or later, blocking MCP endpoints if the upgrade must wait, restricting outbound network access, and giving the gateway workload the narrowest possible cloud IAM role.
Why it matters
An LLM gateway is a credential aggregator by design. It exists so that applications do not each hold a provider key, which means it holds all of them. Administrative access to it is worth more than administrative access to any one model account, and the finding is that a tenth of the exposed ones will hand that over to a string copied from a README.
The pattern connects to the JFrog phantom join key from the week before, and the shared root cause is a default that fails open. Software that runs fine with no credential configured will be run with no credential configured, because nothing in the operator's experience signals otherwise. A gateway that refused to start without an explicit master key would have produced 191 support questions instead of 191 open administrative interfaces.
If you run one: rotate the master key now, treat every provider key it held as compromised and rotate those too, review the prompt and response logs for what an attacker could have read, and put the gateway behind your network boundary. This is static API key abuse, and the reason it keeps paying is that one key opens many doors.
Source: The Hacker News
Related on Start with Identity
- BlogOne actor signed in as Entra ID apps with stolen secrets and reached 27 organizations, Todyl says
Todyl is tracking an ongoing campaign in which one operator uses stolen client secrets to sign in to Microsoft Entra ID as app registrations, reaching 27 organi
- BlogLiteLLM traces its poisoned release to an admin key leaked in May and never revoked
LiteLLM's October 23 attack-chain report says an Agent Platform admin key committed to a public repo on May 27 was deleted but never revoked. On October 10 it r
- BlogAn MLflow SSRF reaches cloud metadata services, and scanning started within hours
CVE-2026-64849 (CVSS 9.3) abuses MLflow's model-registry webhooks to proxy requests into internal services, including cloud metadata endpoints that hand out cre
- CVELiteLLM MCP gateway accepts any Bearer token after key validation fails
LiteLLM's MCP Streamable HTTP endpoint fell back to an empty auth object when key validation failed, so a fabricated Authorization header reached the gateway's
- CVECommvault Web Server zero-day that exposed Metallic Microsoft 365 app secrets
An authenticated webshell flaw in Commvault Web Server, used as a zero-day in Commvault's Azure environment, where the actor may have reached client secrets cus
- ReportIdentity Breach Report 2026: how attackers get in
123 identity breaches, 2021 to 2026: MFA was bypassed in 25 of the 41 with a known MFA status, and 44% of 2025-2026 cases had no login for MFA to protect.