Security1 publisher2 min readPublished
CVE-2026-59822 lets any Bearer token open an MCP session on LiteLLM gateways
LiteLLM's MCP endpoint accepts an arbitrary Bearer token as a valid session, and CISA has already added the bypass to its exploited-vulnerability catalog after Wiz watched attackers use it against honeypots.
The Watch · Security desk
What happened
- Wiz scanned roughly 3,000 internet-facing LiteLLM deployments and found that 9.6 percent of 3,074 public instances accepted the default master key sk-1234 or required no authentication at all.
- CISA has added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog, and Wiz says it recorded exploitation in the wild through its own honeypot infrastructure.
- A second issue, given no CVE and fixed alongside CVE-2026-59821, granted PROXY_ADMIN access to every user whenever no authentication was configured on the proxy.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The gateway holds keys for every backend it fronts, so one default master key puts the provider credentials for Bedrock, Azure and Vertex tenants behind it within reach of whoever finds the port.
- capability An attacker needs no memory-corruption bug to run code on the host: the guardrail feature already accepts admin-supplied Python and executes it, so the intended workflow is the payload path.
- constraint Because the pass-through route has no fix to apply, defenders are limited to egress policy and configuration review on a component shipped as a convenience feature.
- precedent Wiz located these sinks by pointing Claude Code at the codebase for user input reaching execution contexts, a review cheap enough to repeat against every other AI gateway in the same position.
9.6 percent of 3,074 internet-facing instances is about 295 gateways that accept sk-1234 or accept nothing [2][1].
On those hosts the product supplies the first escalation step by itself. Wiz reports that when no authentication is configured, every user is granted PROXY_ADMIN [4]. Administrator on a LiteLLM proxy carries execution rights, not just configuration visibility. Custom code guardrails let an administrator submit Python that the server hands to exec(compile(...)) [9]. Configuration access and code execution are the same privilege here, which is why Wiz describes the result in that population as effectively pre-auth [11].
CVE-2026-59822 is the second door. The MCP endpoint carries its own authentication handler, separate from the main proxy auth, built for a dual model of LiteLLM API keys for direct users and OAuth2 tokens [10]. Wiz says an arbitrary Bearer token there creates a valid session, and that it confirmed the condition across hundreds of internet-facing instances [3]. That one is patched, and it is listed in CISA's Known Exploited Vulnerabilities catalog [5][15].
The step with no patch is the pass-through endpoint feature, which forwards requests to arbitrary URLs with no validation [6]. Wiz reported it as a route to cloud credential theft. LiteLLM does not classify it as a vulnerability, so there is no CVE and no fix, and the technique stays available to anyone already authenticated [6]. Anyone holding the default master key is already authenticated [2].
The KEV listing and the honeypot observations are on the record; what happened on the unauthenticated hosts beyond that is not [5]. The published account does not name a victim, does not say how many exposed instances were actually taken, and does not give a remediation date [17].
The billing framing is Wiz's own starting point: the usual concern about an exposed gateway is LLMjacking, someone running inference on the organization's bill and lifting whatever provider keys are configured [12]. What sits behind the same session is a host that runs server-side Python on every inference request, can proxy to internal URLs, and holds credentials for more than 100 providers including AWS Bedrock, Azure and Google Vertex AI [13][8][1]. Wiz puts LiteLLM in roughly a third of the cloud environments it sees [7]. Two of the three paths have patches; the pass-through path has a configuration decision instead, and no version bump makes it [15][6].
What to watch
- A LiteLLM decision to add URL validation to pass-through endpoints would remove the only step in this chain that currently has no fix.
- Honeypot or KEV telemetry showing attackers moving past MCP session creation into guardrail code execution would change the exploitation picture.
- A rescan of internet-facing deployments would show whether the 9.6 percent unauthenticated population is falling after disclosure.