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
- 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
- BlogGhostSplice splits a malicious instruction across MCP tool calls, and refusal rates go to zero
ASSET Research Group fragmented an exfiltration request across MCP channels so no single piece looked malicious. Models that refused the intact instruction 100
- Blog24,650 exposed server management interfaces leak crackable password hashes before login
Firmware security firm Lava found that 67 percent of 36,872 internet-exposed Baseboard Management Controllers hand over IPMI authentication hashes before a logi
- GlossaryAPI Key
A static secret string used to authenticate an application or caller to an API. Simple but weak: it does not expire on its own, is easy to leak, and should be v
- GuideAPI Key Rotation Automation Guide
A practical guide to automating API key rotation with zero downtime, covering rotation strategies, secrets management integration, dual-key patterns, monitoring
- VendorAzure Key Vault
strong_contender