One in ten exposed LiteLLM gateways still answers to sk-1234: your AI gateway is a tier one security asset now

On 10 September, The Hacker News summarised a Wiz Research report in one line that reached 2.3 million followers: one example LiteLLM admin key was accepted by nearly 1 in 10 gateways. Researchers found 294 of 3,074 internet facing instances accepted sk-1234, the placeholder in the project's own setup guide, and in tests that access reached cloud IAM credentials.

Our tracker counted 105 X and Reddit posts about the LiteLLM CVEs between 3 and 10 September. They arrived in two waves, and the second one is still building as this goes out.

The first wave followed CISA. On 2 September the agency added CVE-2026-59822, an improper authentication bug in LiteLLM's MCP endpoint, to its Known Exploited Vulnerabilities catalog with a federal patch deadline of 16 September. The second wave followed Wiz publishing the full research on 9 September under the title Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise, and the trade press picking it up the next morning.

This post is not about LiteLLM being bad software. It is the most widely deployed open source gateway in the category, Wiz puts it in roughly a third of cloud environments, and every issue described here was disclosed responsibly and patched. This post is about what the findings say about the position an AI gateway occupies, because that position is the same whichever gateway you run. It is also the security half of a question that surfaced in five subreddits this week, which we cover separately: why every agent on one shared key breaks attribution.

What the research found

Four findings, in Wiz's own framing, plus one scan result:

1. MCP authentication bypass, CVE-2026-59822, CVSS 8.8. The MCP endpoint had a dual authentication path: LiteLLM keys for direct users, OAuth2 passthrough for upstream providers. When a token failed LiteLLM validation, the handler caught the 401 and returned an empty auth object instead of rejecting. Any string after Bearer produced a valid MCP session. Wiz demonstrated it with a single character. Fixed in v1.84.0 on 25 April.

2. Post auth root level remote code execution, CVE-2026-59821. Custom code guardrails let admins submit Python that runs on every inference call. The UI test path sandboxed it; the registration endpoint did not, so submitted code got full builtins and executed as the process user, root in the default container. Fixed in v1.82.0 on 25 February.

3. Unauthenticated admin by default. When no authentication was configured, every request was granted PROXY_ADMIN. Fixed alongside the RCE by changing the default role to INTERNAL_USER.

4. Cloud credential theft via pass through endpoints. Admins can define proxy routes that forward to arbitrary URLs with no validation against private ranges or metadata services. Point one at 169.254.169.254 and the gateway hands back the IAM credentials of the role it runs under. Wiz notes this was not classified as a vulnerability and remains available post authentication.

5. The scan. Of 3,074 public instances visible on Shodan at the time of the February research, 9.6% accepted sk-1234 or required no authentication. As Wiz put it, in those cases the RCE is effectively pre auth. The master key doubles as the HS256 secret for session JWTs, so an unchanged default is not one credential, it is the ability to mint any credential.

CISA's catalog shows the pattern: CVE-2026-42208 (SQL injection, added 8 May), CVE-2026-42271 (command injection, added 8 June) and now CVE-2026-59822. Three KEV entries for one gateway in four months, with the last two both on the MCP surface. A r/linuxadmin poster made the operational point on 3 September: the June bug was chainable with a Starlette host header flaw that is also in this KEV batch, so it is worth confirming you are past both fixes, "not just the newest one."

Why the gateway is the highest value target in your stack

The Wiz report's most useful sentence is not about any CVE. It is this: these systems "need to be treated as Tier-1 security assets rather than developer tools." The same week, DeepSeek showed the other reason the gateway layer matters, by redirecting three pinned model ids to a new model on four days' notice: the gateway is where you see which model served each request.

Think about what an AI gateway holds by design:

• Every provider API key for every model your organisation uses, in one process, decrypted in memory.
• Every prompt and every response that passes through, including whatever your users pasted into them.
• Connections to internal tools via MCP: Jira, Slack, databases, CI pipelines. Wiz notes that LiteLLM's documentation recommends the allow_all_keys flag for "low risk utilities where every team should be able to connect," which the empty credential from the bypass also satisfies.
• A cloud identity, because the container runs under an IAM role that can reach the metadata service.
• Server side code execution on every request, because that is what guardrails and hooks are.

A compromised gateway is not one leaked key. It is all of them, plus the conversations, plus a foothold on the tools, plus the cloud role. The conventional risk model for a leaked LLM key is LLMjacking: someone runs inference on your bill. Wiz set out to show the ceiling is much higher, and did.

A r/mlops thread from 7 September, written before the Wiz report landed, described the same structural problem from the operator's side. The author argued that a self hosted gateway is two completely different jobs mashed into one process: a stateless translator that reshapes API calls, and a control plane that "holds your provider keys, tracking budgets, logging audit trails, and enforcing guardrails." By default they live together, "your provider API keys are sitting right next to admin panels and tool servers," and when the translator gets a CVE the whole vault is exposed. Their fix was to split them. That is the right instinct, and it is also a description of what a managed gateway is.

How this happens to competent teams

Nobody chooses sk-1234 for production. It ends up there because the setup guide uses it, the docker compose file ships with it, the gateway is stood up as a developer convenience on a Friday, and six months later it is fronting production traffic with the config nobody revisited. One reply to the Hacker News post put it plainly: "we've all left a placeholder somewhere that became infrastructure."

The corpus is full of the pattern in smaller forms. On 8 September a developer asked X what to run as a personal AI gateway on a Mac mini to log every token to a database, "just spin up litellm?" On 7 September an r/ciso poster asked how other companies stop citizen developers sharing plain API keys with their coding agents, because DLP covers Slack and the chat clients but not the terminals where the agents run. On 9 September an r/sysadmin thread listed the whole surface: VS Code extensions, coding agents, MCP servers, local agents, with the questions "how do you prevent API keys, passwords, or internal data from appearing in prompts?" and "how do you handle MCP servers and their sometimes very broad permissions?"

Every one of those is a gateway question, and every one of those gateways will hold provider keys. The default outcome of the current adoption wave is thousands more instances stood up by people whose job is not running secure infrastructure. One security account made the forecast on 10 September: "default keys with root access is the story of every infra layer's first year," and LiteLLM "won't be the last MCP tool caught in this phase."

If you run your own gateway

This is the Wiz remediation list with the operational detail added, and it applies to any self hosted gateway, not only LiteLLM:

1. Rotate the master key today and confirm nothing in your fleet still accepts the default. Because the master key signs session tokens, rotating it invalidates every session that may have been minted while it was default. That is the point.
2. Get past every fix, not the latest one. For LiteLLM that means at least v1.84.0 for the MCP bypass and v1.82.0 for the RCE, and Wiz's timeline shows the config update endpoint was fixed separately in v1.83.0. Pin the version; do not float on latest.
3. Take the admin surface off routable interfaces. The MCP endpoint, the admin UI and the config endpoints should not be reachable from the internet, and should ideally not be reachable from the same network as the inference path.
4. Block the metadata service from the gateway container. Egress rules that deny 169.254.169.254 and the equivalent on your cloud close the pass through vector regardless of what the application allows.
5. Give the container a least privilege role. If the gateway's IAM role can only do what a gateway needs, credential theft yields little.
6. Audit guardrails and pass through configs for entries you did not create, and restart the process to clear anything resident in memory.
7. Patch on a production SLA. A gateway sits in front of production traffic; it needs the same patch cadence as the API it fronts. Three KEV entries in four months is the cadence to plan for.

If you would rather not run one

The honest version of the build versus buy argument has always been about operations, and this is the week it stopped being abstract. Every finding above is an operational property: a default that was never changed, a version that was never bumped, a panel that was reachable, a container with too much identity. None of them is about routing quality.

A managed gateway takes those off your plate by construction. The provider keys never live on a box you administer. There is no master key in a compose file. The admin surface is not on your network. Patching is not your ticket queue. What remains yours, and what still matters, is the policy layer: which keys can call which models, how much each can spend, and where the prompts are allowed to go.

That is the layer Requesty is built around, and it maps directly onto the failure modes in the Wiz report:

• Per key scoping instead of one master credential. Every API key carries its own spend limit, its own access list of approved models, and its own expiry, managed through the key management API. A leaked key is one scoped credential with a monthly cap, not the vault.
• Provider keys stored once, used through policy. Bring your own keys puts your OpenAI or Anthropic credentials in encrypted storage that your application code never touches; the application holds a Requesty key, and the routing policy decides which upstream key is used.
• Per user MCP credentials. For MCP, user key management means each person's Jira or GitHub token is theirs, encrypted at rest and audit logged, rather than one shared connection every key can reach.
• Guardrails without server side code. Organisation guardrails run PII and secret scanners you configure, not Python you upload, so the guardrail feature is not an execution surface.
• Logging you control. Data privacy controls let you turn payload logging off per key or enforce zero data retention org wide, so a breach of the logging layer does not become a breach of every conversation.

The comparison pages for LiteLLM and the open source router build versus buy piece cover the feature trade offs. This post covers the one that got repriced this week: the cost of being the person responsible for the box.

The takeaway

The category grew up this month. An AI gateway is now in CISA's exploited catalog three times, and a scan of the public internet found the example password on one instance in ten. Neither fact is a surprise to anyone who has watched a new infrastructure layer go through its first year, and neither is specific to one project.

What is specific is the blast radius. A gateway holds the keys, reads the prompts, connects to the tools and carries a cloud identity. Treat it the way you treat your identity provider. If you run your own, patch it this week, rotate the master key and take the admin surface off the internet. If you would rather not carry that, pick a gateway where the vault, the panel and the patch cadence are someone else's job, and spend your effort on the policies that limit what any single key can do.