Security & Governance

The First MCP CVE on the KEV List Hit Its Federal Deadline: LiteLLM and the Default-Key Vault

By IdeaBosqueLast updated: September 15, 2026

CVE-2026-59822 is an authentication bypass in BerriAI's LiteLLM proxy — the open-source gateway that routes traffic between applications and more than 100 model providers — and it reached its federal remediation deadline on September 16, 2026. CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 2 with a due date of today under BOD 26-04, making it the first Model Context Protocol implementation ever listed as actively exploited by a national vulnerability-management authority (NVD; The Hacker News). The exploitation is not theoretical: Wiz's honeypot infrastructure observed CVE-2026-59822 being used in the wild on July 7 — 56 days before the KEV listing (Wiz). And the CVE is not even the most common way into these gateways. Wiz's February 2026 scan of 3,074 internet-facing LiteLLM instances found 294 — 9.6% — accepting the example master key sk-1234 printed in LiteLLM's own documentation, and 191 with no authentication configured at all (Wiz; The Hacker News).

This article covers four things a Head of Engineering or platform lead needs before the next audit finds a LiteLLM instance on their network: how the bypass works in one request, why the master key makes the gateway a cloud credential vault, what the KEV deadline actually requires, and the six verification items that close the exposure — plus the code pattern to ban from every MCP authentication handler you own.

Key takeaways

CVE-2026-59822 is the first MCP-specific CVE on CISA's KEV list — added September 2, 2026 with a federal remediation deadline of September 16, 2026, at CVSS 8.8, affecting all LiteLLM versions before 1.84.0.
Wiz's honeypot observed exploitation on July 7, 2026 — 56 days before the KEV listing — with a single-character Bearer token establishing a fully authenticated MCP session.
294 of 3,074 internet-facing LiteLLM gateways (9.6%) accept the documented example master key sk-1234 or no authentication at all — 191 of them require no credential whatsoever, per Wiz's February 2026 Shodan scan.
The master key is a cloud credential vault: a valid administrator (or attacker holding the key) can use pass-through routing to read AWS instance metadata and retrieve IAM credentials, and IMDSv2 does not stop it because the proxy forwards x-pass--prefixed headers.
The bypass is a code pattern, not just a bug: catching a failed authentication and substituting an empty auth object. ACM-published "Puppet" research shows this confused-deputy class reaches 90.89% tool-selection hijack success while remaining invisible to MCP-Scan and McpSafetyScanner.

The 24-hour clock, and how the bypass works in one request

The timeline matters because it shows the exploitation ran ahead of the federal response at every stage. Wiz reported the vulnerability to LiteLLM maintainers on February 18, 2026; the fix shipped in LiteLLM 1.84.0 on April 25; Wiz's honeypot recorded real-world exploitation on July 7; the flaw was published July 8; CISA added it to the KEV catalog on September 2 — and set the remediation deadline 14 days later (Wiz; NVD).

The mechanism is a fail-open fallback in LiteLLM's MCP endpoint. The endpoint supports two authentication patterns: native LiteLLM keys and OAuth2 tokens passed through to an upstream MCP server. When a Bearer token fails LiteLLM key validation with a 401 or 403, the handler is supposed to forward the token upstream. Instead, it catches the error and returns an empty UserAPIKeyAuth() object — an authenticated session with no identity behind it (Wiz; GitLab advisory database). Wiz's demonstration used Authorization: Bearer a — a single character — and received HTTP 200 with a valid mcp-session-id.

What that session can reach depends entirely on deployment configuration. A gateway with a database query tool connected hands the attacker query access; GitHub integration hands over repository reads and issue creation; filesystem connectors hand over read-write file access. LiteLLM's documented allow_all_keys flag — recommended by LiteLLM itself for "low-risk utilities" — makes every configured MCP server reachable by the empty credential the bypass creates (Hive Security). The blast radius is not the proxy. It is every system the proxy's MCP servers touch.

Three failures, one gateway

Wiz's research surfaced four distinct problems in LiteLLM with different preconditions — flattening them into one "magic chain" misstates both the severity and the response (Wiz):

CVE-2026-59822 — the MCP authentication bypass. Unauthenticated, one request, versions before 1.84.0. Fixed in 1.84.0.
CVE-2026-59821 — root-level code execution via custom guardrails. The guardrail registration endpoint passed administrator-submitted Python to exec() without the sandbox (builtins-stripping, forbidden-pattern checks) applied on the UI's test path. Wiz observed code running as root in the proxy container. Fixed in 1.82.0-stable. This one required admin access — but combined with failure mode 3, it becomes effectively pre-auth.
Default or missing authentication. The 294-of-3,074 scan result. When no master key is configured, LiteLLM granted every caller PROXY_ADMIN access — a no-CVE design behavior fixed alongside CVE-2026-59821.
Pass-through routing to cloud metadata. An authenticated administrator can point a pass-through route at the AWS instance metadata service and forward the IMDSv2 session-token header through the proxy's x-pass- prefix-stripping behavior. Wiz and LiteLLM classify this as intended administrator behavior — no CVE, no fix. But once a default or leaked master key erases the assumption that only trusted administrators hold the key, this "intended" capability becomes the path from application compromise to cloud account compromise (CSA).

The compounding is the story. LiteLLM holds API keys for every configured model provider — OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI — and roughly one-third of surveyed cloud environments run a deployment (CSA). CSA's research note calls the master key configuration "a cloud credential vault." The vault has already been emptied once: in a publicly disclosed August 2026 compromise, an attacker with code execution on a gateway host read the container's environment variables, recovered the master key and a database connection string, and copied records directly out of the gateway's backing PostgreSQL database (CSA).

A patched instance is not a safe instance. A gateway patched to 1.84.0 that still answers to sk-1234 is compromised by anyone who knows the default — which is everyone who has read the README.

What the KEV listing actually requires

The Known Exploited Vulnerabilities catalog is not a severity ranking. It is an active-exploitation finding with a binding clock: under BOD 26-04, federal civilian agencies must apply vendor mitigations by the due date or discontinue use of the product, and agencies must triage internet-facing instances first. The deadline that lands today applies directly to federal agencies — but its effect reaches further, because a growing number of cyber insurance policies and vendor risk questionnaires reference the KEV catalog as a baseline (Tech Insider). An unpatched CVE-2026-59822 instance is now an audit finding for any organization whose compliance regime inherits the KEV list, whether or not that organization is a federal agency.

The milestone matters for the protocol, not just the product. CVE-2026-42271 — LiteLLM's testing-endpoint command injection, added to KEV in an earlier batch — was MCP-adjacent. CVE-2026-59822 is MCP-specific: the exploited surface is the MCP Streamable HTTP endpoint and its authentication handler. The first MCP vulnerability with a federal remediation mandate signals where the next ones will come from. UltraViolet Cyber's threat advisory counts 40+ CVEs disclosed against MCP implementations in 2026 alone (UltraViolet Cyber), Bitsight's internet scan found roughly 1,000 exposed MCP servers serving full tool inventories with no authorization (Bitsight), and Practical DevSecOps measured 30–82% of public MCP servers carrying exploitable flaws (Practical DevSecOps). The exposure stack behind the first KEV listing is not an outlier. It is the population.

The diagram below compresses the incident into one minute: the timeline that ran ahead of the federal response, the four failure modes that share one gateway, and the six verification items that close the exposure.

The six verification items

The MCP security hardening checklist this article's parent distills into 12 controls now gains a gateway-specific supplement. Six items, each verifiable in minutes:

Fail closed, provably. Send Authorization: Bearer x to the gateway's /mcp/ endpoint. A correctly configured instance returns 401 or 403. A vulnerable instance returns 200 with a session ID. This is the CVE-2026-59822 test, and it takes one request.
Inventory and upgrade. Find every LiteLLM instance — including shadow deployments in developer stacks — record its version and image digest, and pin a current stable release. 1.84.0 first fixed CVE-2026-59822; 1.82.0-stable fixed CVE-2026-59821; later advisories exist, so do not freeze on either minimum (Hive Security). If an immediate upgrade is impossible, the advisory's interim mitigation is blocking /mcp/ and related routes at the edge.
Rotate the master key and everything behind it. Replace sk-1234 and any reused key. If exposure or suspicious access is suspected, rotate model-provider, database, OAuth, and MCP-connected service credentials and revoke derived sessions — the documented compromise chain shows a gateway compromise cascading directly into a provider-key leak and a database dump (CSA).
Scope MCP tool access. Remove allow_all_keys from sensitive integrations, separate read from write tools, and require per-team authorization. The bypass grants whatever the session can reach — the tool configuration is the blast radius.
Contain the control plane. Remove public exposure unless explicitly required, deny workload access to cloud metadata services, allowlist egress destinations, and run the container as non-root without privileged mounts. IMDSv2 does not defend this path, because the proxy can make the token request and forward the headers itself (Wiz).
Hunt the logs before they expire. Review reverse-proxy and LiteLLM logs for /mcp/ sessions authenticated with junk-looking tokens, unexpected tool calls, guardrail creation events, and pass-through configuration changes. Correlate with process, DNS, and cloud audit logs — and preserve evidence before restarting, since a restart clears in-memory state but does not revoke a stolen credential (Hive Security).

Items 1 and 3 are the deadline-day priority: the first proves the vulnerability, the second closes the standing exposure that outlives any patch.

What this means beyond LiteLLM

Two patterns generalize, and both belong in every MCP authentication review from here forward.

First: fail-open fallbacks are a code smell, not a LiteLLM bug. The bypass is three lines — catch the 401, substitute an empty auth object, proceed. Any MCP proxy that delegates authentication to an upstream provider through a passthrough fallback carries the same class. The fix is a review standard, not a version bump: when upstream validation fails, the request terminates. It never proceeds with an unauthenticated identity.

Second: gateways are control planes, and confused-deputy research says they fail at the metadata layer. ACM-published "Puppet" research evaluated confused-deputy attacks across 14 models on 2 MCP hosts and measured tool-selection hijacking rates up to 90.89% and end-to-end payload execution up to 86.46% — while remaining undetectable by MCP-Scan and McpSafetyScanner, which are architecturally incapable of catching metadata-level manipulation (ACM). A gateway that concentrates model credentials, prompt visibility, and tool access behind one authentication boundary is the same concentration CSA's AI Controls Matrix flags for identity and secrets-management controls (CSA). The operational translation: authenticate the gateway like a control plane and contain it like a breach boundary — least-privilege IAM, no default credentials, metadata unreachable, egress allowlisted.

The broader context is a protocol maturing from "optional authorization" to federal enforcement. Bitsight's December 2025 scan found roughly 1,000 exposed MCP servers with no authorization (Bitsight); Wiz's August 2026 honeypot analysis documented active campaigns targeting LiteLLM, MCP servers, and AI frameworks through RCE, blind prompt injection, and memory credential theft (Wiz); and a third LiteLLM authentication bypass — CVE-2026-49468, a Host-header injection disclosed May 28, 2026 — completes a 2026 pattern where the same product shipped three distinct authentication failures in one year (GitHub advisory). The KEV listing is the point where that pattern stops being a research topic and becomes a compliance line item.

The MCP 2026-07-28 specification moved the protocol to a stateless core and the ecosystem's authorization work is moving toward OAuth 2.1 with audience-bound tokens. Architecture closes entire vulnerability classes. But the LiteLLM incident proves the operational layer decides outcomes: a stateless, spec-compliant deployment that still accepts its example master key is still compromised. Patch the CVE, then audit the defaults — in that order, before the next deadline.