LiteLLM MCP Auth Bypass 2026: How a One-Character Token and Default Master Keys Exposed AI Gateway Credentials

On 2 September 2026, CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalogue. The bug is in LiteLLM, a widely used open-source gateway that sits in front of AI model providers and, increasingly, MCP tool servers. When LiteLLM failed to validate a token on its MCP endpoint, it fell back to an empty authentication object instead of rejecting the request. Any bearer token, even the single character "x", opened a full MCP session. Wiz, which found the flaw, saw attackers exploit it in its honeypots, pull the LiteLLM master key straight from process memory, harvest provider API keys and deploy cryptominers. Separate Wiz research found that nearly one in ten internet-facing LiteLLM gateways accepted the example master key sk-1234 or required no authentication at all. It is a textbook case of an AI gateway's concentrated secrets undone by a fail-open authentication check and a default credential.

At a glance

What happened

LiteLLM gives teams a single OpenAI-compatible API in front of many model providers, with key management and spend tracking. It also brokers MCP tool servers that connect AI agents to databases, code repositories and internal services. Wiz sums up why that matters: "A LiteLLM proxy can hold keys for every model provider it routes to... It may also run with cloud IAM permissions and connect to internal services through MCP tool servers."

Wiz Research found CVE-2026-59822 in LiteLLM's MCP gateway. LiteLLM supports OAuth2 passthrough, where a bearer token is meant for an upstream MCP server. When LiteLLM's own key validation failed, the fallback "could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object" instead of returning a 401, according to the GitHub advisory quoted by Skycloak. Downstream code treated that as a caller with no limits. Wiz says "Any Bearer token (even just a single character, e.g., x) grants full MCP access." Skycloak reports that the same fix also closed a second bypass, in which adding ?.well-known to an MCP URL marked the route as public. Both are fixed in LiteLLM 1.84.0.

In a 90-day honeypot study published on 27 August, Wiz saw the bypass exploited and chained with CVE-2026-42271, a command injection in LiteLLM's MCP server test endpoints, to run code. Rather than search the disk for credentials, attackers queried the running process's Python state for master_key and litellm_master_key_hash. They also looked for LiteLLM configuration files, fingerprinted which models were reachable, and deployed XMRig miners in paths chosen to blend in, deleting their staging directories. CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalogue on 2 September 2026, with a remediation deadline of 16 September for federal civilian agencies.

On 9 September, Wiz published wider research on breaking LiteLLM. Of 3,074 internet-facing LiteLLM proxies scanned in February 2026, 294 (9.6%) accepted the default master key sk-1234, and 191 (6.2%) had no authentication at all. The master key is the admin credential and also the HS256 secret that signs session JWTs, so a default key lets anyone forge sessions. Wiz also showed that an admin can create pass-through routes to any URL, including the cloud instance metadata service. By forwarding headers, even IMDSv2 protections could be defeated to retrieve IAM credentials. Wiz says that, as of 9 September, the master key still defaulted to sk-1234 when LiteLLM is installed via Docker Compose or pip.

Timeline

How it happened: the identity attack path

1. A gateway that concentrates secrets. LiteLLM holds provider API keys, a master key, and credentials for the MCP tool servers and cloud resources behind it.
2. Fail-open authentication. A failed token check produced an empty, unrestricted identity instead of a rejection, so a fake bearer token became a working session.
3. Default admin credentials. Nearly one in ten exposed gateways accepted the documented example key or had no authentication, giving admin access without any exploit.
4. Secrets read from memory. Once in, attackers read the master key from the running process and harvested provider keys, which bypasses controls that only watch credential files.
5. A path to the cloud. With admin access, pass-through routes can reach the instance metadata service and return the host's IAM credentials.
6. Code execution and monetisation. Chained with the MCP test-endpoint command injection, access became code execution and cryptomining.

Impact

• Exploitation: confirmed in the wild by CISA's KEV listing and observed by Wiz, including master key and provider key theft and cryptominer deployment.
• Exposure: 294 of 3,074 scanned gateways accepted a default key in February 2026, and Wiz confirmed the MCP bypass as exploitable across hundreds of internet-facing instances.
• Credential blast radius: model provider keys, MCP tool credentials and potentially cloud IAM credentials on every exposed, unpatched gateway.
• Victims: no specific organisations have been named publicly.

What this means for NHI and AI agent security

AI gateways have quietly become some of the most credential-dense systems in many organisations. One LiteLLM instance can hold keys for every model provider, the master key for the gateway itself, and credentials for the MCP servers that reach databases, source control and ticketing systems. That makes it an identity boundary, but teams often deploy it like plumbing: fast, exposed, and protected by a shared static key.

CVE-2026-59822 shows why authentication must fail closed. A failed check that turns into a default identity is a bypass waiting to be found. The default-key research shows the older problem of machine credentials that are never changed, now applied to AI infrastructure. Both lead to the same place: stolen provider keys fuel LLMjacking, and stolen tool credentials reach systems of record. Our LLMjacking Guide and MCP Security Guide cover the controls. This is also LiteLLM's second appearance on our list, after the LiteLLM PyPI package breach earlier in 2026.

Recommendations

• Patch and verify. Upgrade LiteLLM to 1.84.0 or later. If you cannot, block /mcp/ routes at your reverse proxy.
• Replace default master keys. Set a strong, unique master key and check every deployment for sk-1234 or no authentication. See our API Key Management Guide.
• Take gateways off the public internet. Put LiteLLM and its MCP routes behind private networking or an identity-aware proxy that validates tokens before they reach the gateway.
• Rotate everything the gateway held. If an exposed instance ran a vulnerable version, rotate the master key, every provider key and the credentials of connected MCP servers. Use our Leaked Credential Response Playbook.
• Limit the gateway's cloud identity. Give the host a least-privilege IAM role and block or tightly control access to the instance metadata service. See our AI Infrastructure Workload Identity Guide.
• Give callers their own identities. Replace one shared gateway key with named clients and short-lived, audience-restricted tokens so access can be traced and revoked per caller.

Frequently asked questions

What is CVE-2026-59822?

It is an authentication bypass in LiteLLM's MCP Streamable HTTP endpoint in versions before 1.84.0. When key validation failed, LiteLLM substituted an empty authentication object instead of rejecting the request, so any bearer token opened an authenticated MCP session.

Is it being exploited?

Yes. CISA added it to the Known Exploited Vulnerabilities catalogue on 2 September 2026, and Wiz observed it being exploited in its honeypots, chained with CVE-2026-42271, to steal the master key and provider keys and deploy cryptominers.

Does patching make my provider keys safe?

No. Patching closes the hole but does not undo exposure. If a gateway was internet-facing and unpatched, or used the default master key, rotate the master key, all provider API keys and the credentials of connected MCP servers.

Related NHI Mgmt Group resources

LiteLLM PyPI package breach · JADEPUFFER agentic ransomware 2026 · LLMjacking attacks on AI API keys · MCP Security Guide · Secrets Management Guide

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as AI gateways gather provider keys, tool credentials and cloud access in one place. Our NHI Foundation Level Training Course gives teams the practical grounding to protect them.

References

• Wiz: Attacks on AI Infrastructure: 90-Day Honeypot Telemetry (27 August 2026)
• ZeroDayHub: CVE-2026-59822: LiteLLM MCP Auth Bypass Exploited (8 September 2026)
• Wiz: Breaking LiteLLM: From Auth Bypass to Cloud Compromise (9 September 2026)
• Skycloak: CVE-2026-59822: LiteLLM's MCP Auth Bypass, and the Second Bug in the Same Fix (21 September 2026)