Nearly 1 in 10 Exposed LiteLLM Gateways Still Accept the Documentation's Own "sk-1234" Admin Key

Internet-facing LiteLLM AI gateway deployments

Wiz Research scanned 3,074 publicly reachable LiteLLM instances found through Shodan and reported on September 10, 2026 that 294 of them, 9.6%, accepted `sk-1234`, the example master key printed in LiteLLM's own quickstart guide, and that 191 instances, 6.2%, had no key configured at all. The master key is not a limited credential: holding it exposes every model provider API key stored on the gateway, the prompts and responses passing through it, any internal tooling wired in over the Model Context Protocol, and, in Wiz's tests, the cloud IAM credentials of the host itself by way of the instance metadata service. The exposure sits alongside a cluster of LiteLLM flaws, among them the actively exploited CVE-2026-59822 (CVSS 8.8) authentication bypass that lets any Bearer token open an authenticated MCP session, CVE-2026-42271 (CVSS 8.7) authenticated command execution on the host, CVE-2026-59821 post-authentication code execution through Custom Code Guardrails in versions before 1.82.0, and CVE-2026-40217, a sandbox escape to root-level execution. A follow-up scan in August returned more than 85,000 instances, though Wiz assessed most of those as honeypots or test systems. LiteLLM's security policy states that attacks requiring a setup mistake such as a missing master key are not in scope and are not treated as vulnerabilities. Recommended remediation is upgrading to 1.84.0 or later and replacing the default key

A documented example credential that works in production, on a component that by design holds every downstream provider key an organization owns. The vendor treats the unrotated default as a deployment error rather than a defect, which leaves the failure mode permanently outside anyone's patch cycle