LiteLLM: 9.6% of Exposed Instances Vulnerable to Auth Bypass and RCE

On September 9, 2026, Wiz research disclosed a scan of 3,074 internet-exposed LiteLLM instances: 9.6% accept the default master key "sk-1234" or require no authentication, making a pre-authentication attack feasible that chains an MCP bypass to remote code execution with root privileges. CVE-2026-59822, the authentication bypass for the Model Context Protocol, is already in the CISA Known Exploited Vulnerabilities catalog with confirmed in-the-wild exploitation.

"Nearly 1 in 10 publicly accessible LiteLLM instances accept a default master key or require no authentication at all"

The MCP Bypass Mechanism: When a 401 Becomes a Valid Session

The Model Context Protocol (MCP), developed by Anthropic and adopted by LiteLLM to extend LLM gateways to external tools, requires authentication via Bearer token. According to Wiz research, the file user_api_key_auth_mcp.py handles validation with flawed logic: any arbitrary token, even a string like "a", triggers a 401 error that the handler catches and converts into an empty but valid authentication object.

The effect is immediate. The attacker obtains an authenticated session without possessing valid credentials, gaining access to connected MCP tools: databases, GitHub repositories, local filesystems, CI/CD pipelines. The finding emerges from a real scan of public instances, not theoretical code analysis. The source does not specify how many of these instances actively exposed sensitive MCP tools, but the attack surface is structural.

"Any garbage token fails validation with a 401, and the handler proceeds as if nothing happened"

From Bypass to Execution: How the Default Key Enables Root-Level RCE

The second vulnerability, CVE-2026-59821, resides in LiteLLM's custom code guardrails module. The function _compile_custom_code() in custom_code_guardrail.py executes exec(compile(...)) on user-supplied code without stripping __builtins__ and without forbidden pattern checks. The result is RCE with root privileges at the moment the guardrail is registered.

The research documents that execution occurs during initialization, not upon subsequent invocation. "The code executes immediately when the guardrail is registered, since the import os and os.popen('id') run during initialization." This timing eliminates any detection window based on end-user behavior.

The combination with CVE-2026-59822 and insecure configurations amplifies the risk. When authentication is not configured, LiteLLM automatically assigns the PROXY_ADMIN role to all users. No dedicated CVE is required: the condition was addressed alongside CVE-2026-59821. With PROXY_ADMIN and the default key, the attacker does not need to compromise existing accounts.

One-Third of Cloud Environments: The Scope of a Compromised Gateway

LiteLLM serves as a gateway for over 100 LLM providers. According to Wiz data, it is present in roughly one-third of cloud environments monitored by the platform. This ubiquity turns a product vulnerability into an infrastructure perimeter problem: the LLM gateway is no longer a simple API proxy, but an execution environment with an extended attack surface.

The pass-through endpoint adds a complementary vector. The lack of URL validation allows theft of cloud credentials post-authentication, effectively pre-authentication when the default key or absent authentication are present. The dossier does not specify which cloud providers are most affected by this exfiltration channel.

The research was presented at DEF CON 34. All identified vulnerabilities have been patched following responsible disclosure. The source does not detail specific vulnerable versions beyond the formula "before the fix."

Immediate Actions

Operators managing LiteLLM instances must immediately verify MCP authentication configuration. The Wiz scan indicates 9.6% of public instances are exposed: anyone running LiteLLM in production must confirm the default master key "sk-1234" has been replaced and that authentication is mandatory, not optional.

For the custom code guardrails module, it is necessary to verify the instance runs the patched version. The _compile_custom_code() function in vulnerable versions executes exec() without isolation: updating to the fixed version introduces the missing checks on __builtins__ and forbidden patterns.

The presence of LiteLLM in roughly one-third of cloud environments demands an accurate inventory of deployments. Internal instances not directly exposed to the internet remain vulnerable if accessible from compromised lateral networks. The inclusion of CVE-2026-59822 in the CISA KEV catalog imposes high remediation priority for federal agencies and urges urgency for the private sector.

Questions and Answers

What makes CVE-2026-59822 "pre-authentication" if it requires a Bearer token?

The token can be arbitrary: validation fails with a 401, but the handler generates an authenticated session anyway. Any string works, so no knowledge of valid credentials or prior compromise is required.

Why is the RCE "root-level" and not limited to the service user?

The guardrail code executes via exec() with __builtins__ intact. The source documents execution of os.popen('id') with elevated privileges, indicating the LiteLLM process runs with root permissions.

The fix is available, but who is actually updated?

The scan of 3,074 instances shows 9.6% maintain insecure configurations. The data does not distinguish between unpatched instances and patched instances reconfigured with weak keys. The source provides no temporal trend on patch adoption.

Information is based on the cited source and current as of publication.

Sources

• https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise