Back Home

AI 基礎設施安全

LiteLLM Testing Finds 9.6% of Public Gateways Accept Default Keys; MCP Flaw Can Turn Any Token Into a Valid Session

Wiz scanned 3,074 public LiteLLM instances and found that 294 accepted `sk-1234` or required no authentication at all, including 191 with no authentication configured. Newly disclosed real-world measurements show how an authentication bypass in older MCP implementations, Python-executing guardrails, and access to cloud metadata can be chained into a cross-layer attack path.

Internet Archive Book Images · No restrictions · Image source
zh-Hant

On September 9, Wiz published its [research into LiteLLM’s attack surface](https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise). Using Shodan, researchers found 3,074 public gateways in February 2026. Of those, 294—or 9.6%—either accepted the example administrative key `sk-1234` from the documentation or required no authentication; 191 fell into the latter category. The noteworthy development is not a new CVE, but measurements of public deployments and honeypot observations: Wiz says the MCP authentication bypass has been actively exploited.

The core vulnerability, CVE‑2026‑59822, lies in the separate authentication path for MCP Streamable HTTP. The system was designed to pass an unrecognized Bearer token upstream as an OAuth2 token, but the failure branch created an empty `UserAPIKeyAuth` object. This allowed an attacker to use any token to establish an authenticated session, enumerate the MCP tools connected to the gateway, and invoke them. The [GitHub Security Advisory](https://github.com/advisories/GHSA-7488-6r32-c95q) rates the flaw CVSS 8.8 and says it affects versions earlier than 1.84.0; the patched version blocks this fallback path.

A second attack chain involves Custom Code Guardrails. In older versions, the production create and update endpoints did not apply the sandboxing and validation used by the test endpoint, allowing a privileged caller to submit Python code for execution by the server. When no master key was configured, older versions also treated anonymous requests as `PROXY_ADMIN`. CVE‑2026‑59821 was fixed in version 1.82.0. If a service both retains the default key and runs an outdated version, what was originally authenticated code execution can effectively degrade into a near-unauthenticated attack.

Wiz also notes that the pass-through endpoint can target an arbitrary URL, including the AWS instance metadata service. A caller with administrative privileges can forward headers to complete the IMDSv2 token flow. This capability has not been classified as a vulnerability, so upgrading alone is insufficient to eliminate all risk. Operators should upgrade to at least version 1.84.0, rotate the master key and model-provider keys, remove administrative and MCP routes from the public internet, and use network policies to block link-local metadata access. The scan figures represent only the instances visible at the time of the research, while “obtaining root in the container” still depends on the version, runtime user, and deployment permissions; the findings should not be generalized to mean that every LiteLLM installation can be directly compromised.

Sources

  1. Off Guard: Breaking LiteLLM from Authentication Bypass to Cloud Compromise
  2. LiteLLM: MCP Authentication Bypass via OAuth2 Passthrough Fallback
  3. LiteLLM: Custom Code Guardrails Production Endpoints Bypass Code Safety Checks