Exposed LiteLLM AI Gateways Still Accept the Default sk-1234 Key

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastructure security for US and EU enterprise teams

The short answer

What Wiz found

LiteLLM is a popular open-source AI gateway — the piece of software a company puts between its own applications and the model providers it pays, so that every LLM call flows through one place for routing, budgeting, logging, and key management. That design makes the gateway convenient and also makes it a concentration of secrets: it stores the API keys for OpenAI, Anthropic, AWS Bedrock, Google, and whatever else the organization uses. Whoever controls the gateway controls all of them. Because teams increasingly stand these up while building AI agents and internal copilots, the gateway has quietly become production infrastructure — the kind of component our engineers scope as security-critical in any AI agent build.

In a report published on September 10, 2026, Wiz Research described scanning the internet-facing LiteLLM deployments it could find. Of roughly 3,074 instances located on Shodan in February 2026, 294 — close to one in ten — accepted sk-1234, the placeholder master key that appears in LiteLLM’s own documentation. In 191 of those 294 cases the operators had set no master key whatsoever, meaning the gateway would accept any value at all. A later August 2026 sweep counted tens of thousands more instances, though many looked like throwaway test deployments; the February figures are the conservative, clearly-exposed baseline.

The uncomfortable detail is that this is not an exotic zero-day. It is a documented example credential, copied from a setup guide and never changed, sitting on a service reachable from the open internet. As of September 9, 2026, LiteLLM’s setup guide still printed sk-1234 above a comment telling operators to replace it with a long random value before real use — guidance that, by these numbers, a meaningful fraction of deployments skip.

How a default key becomes cloud compromise

What turns a leftover default into a full breach is that the LiteLLM master key does two jobs at once. It is the administrator credential for the proxy, and it is also the HS256 secret used to sign session tokens. So an attacker who knows the key does not merely log in — they can mint valid tokens for any user and forge arbitrary sessions across the entire gateway, with no configuration change required. When the key is a value printed in public documentation, “knowing” it is trivial.

From that admin foothold, Wiz walked the chain the way an attacker would. First, the gateway hands over every model-provider API key it stores — the paid credentials for each LLM vendor, ready to be abused or resold. Second, and worse, the researchers reached the cloud IAM credentials of the machine the gateway runs on: pass-through endpoints without URL validation let a request be aimed at the cloud metadata service at 169.254.169.254, exfiltrating temporary IAM credentials — even on instances protected by IMDSv2, via header manipulation. At that point the incident is no longer about one gateway; it is about the cloud account behind it.

Two named vulnerabilities sharpen the picture. CVE-2026-59822 (CVSS 8.8) is an authentication bypass in LiteLLM’s Model Context Protocol handling: a flawed fallback treats a request with any bearer token — even Authorization: Bearer a — as authenticated, granting unauthenticated MCP access. It was fixed in v1.84.0 on April 25, 2026 and has since been added to CISA’s Known Exploited Vulnerabilities catalog after real-world exploitation. CVE-2026-59821 is a post-authentication code-execution flaw: custom guardrail code is run through exec/compile with no sandbox, which Wiz used to execute commands as root; it was fixed in v1.82.0 on February 25, 2026. The vendor rates that guardrail issue as low severity, an assessment worth weighing against a demonstrated root shell.

What it means for US & EU software teams

Strip away the product name and three durable lessons remain. First, your AI gateway is a credential vault, so treat it like one. In the rush to ship agents and copilots in 2026, a lot of teams stood up an LLM proxy as “just plumbing” and never gave it the threat model they give a database. But it holds every provider key and, as this research shows, a path to your cloud. The same secure-by-default posture you apply to production data stores — unique secrets, no internet exposure by default, least-privilege roles — belongs on your AI tier and on the wider cloud and DevOps platform it runs on.

Second, defaults are the oldest breach in the book, and AI infrastructure just re-learned it. Default passwords and example keys have been emptying servers for decades; the novelty here is only that the vulnerable box is an AI gateway. Any component whose “getting started” guide contains a literal credential needs a hard, automated check that the example value never reaches production — in CI, in your deployment templates, and in periodic external scans of what you actually expose.

Third, leaked provider keys and cloud pivots are a compliance event, not just an ops headache. For EU teams, unauthorized exfiltration of credentials and any personal or regulated data flowing through the gateway sits squarely inside GDPR, NIS2, and DORA expectations for access control and rapid, documented remediation. For US teams handling health or financial data, the same exposure maps to HIPAA and SOC 2 obligations. Knowing which internal AI services are internet-reachable — and being able to prove they use unique credentials and least-privilege roles — is the control auditors and regulators will ask about first.

What to do now

1. Set a strong, unique master key — and rotate provider keys. Replace sk-1234 or any documented example with a long random value, and rotate every model-provider API key the gateway has stored, on the assumption it may already have leaked.
2. Patch LiteLLM to the latest release. Upgrade past the fixes for CVE-2026-59822 (v1.84.0) and CVE-2026-59821 (v1.82.0), and track the project’s advisories for the related MCP and guardrail issues.
3. Take the gateway off the public internet. An LLM proxy should be reachable only from trusted subnets or behind a VPN or zero-trust proxy. If public access is not a hard requirement, remove it — that alone neutralizes the mass-scanning risk.
4. Lock down the cloud blast radius. Restrict container network egress so the gateway cannot reach the 169.254.169.254 metadata endpoint, apply least-privilege IAM roles to the host, and prefer scoped mechanisms such as IRSA over broad instance roles.
5. Put AI infrastructure in scope for security testing. Gateways, vector databases, and agent runtimes are routinely left out of assessments even though they hold the most sensitive keys. Add them to your next penetration test, review guardrail configs, and restart processes to clear any injected code from memory.

Frequently asked questions

Sources

Wiz Research — Off Guard: Breaking LiteLLM from Authentication Bypass to Cloud Compromise
The Hacker News — Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example “sk-1234” Admin Key
CISA — Known Exploited Vulnerabilities Catalog