本文へ移動
← All articles
observatoryai-securitysupply-chainkevai-gateway

AI Gateways Become the Attack Surface — LiteLLM's KEV Listing and the Path Through Keys, MCP, and the Cloud

In September 2026, CISA added BerriAI LiteLLM's MCP authentication bypass, CVE-2026-59822, to its Known Exploited Vulnerabilities (KEV) catalog (September 2, per Wiz's timeline). The flaw lets an arbitrary Bearer token establish a valid authenticated session on LiteLLM's MCP Streamable HTTP endpoint, and it appeared alongside six other exploited flaws — including SonicWall SMA 1000 and Sangoma Switchvox — in the early-September KEV update (per The Hacker News). LiteLLM is an open-source AI gateway that holds the API keys for every configured LLM provider; by Wiz's estimate it is present in roughly one-third of cloud environments.

The facts: (1) Wiz's research (published September 9) found that of roughly 3,000 internet-facing LiteLLM instances, about 9.6% accepted the default master key sk-1234 or required no authentication at all. In instances without authentication configured, every user was granted PROXY_ADMIN by default, reaching admin functionality without credentials (since fixed). (2) With admin rights, an attacker can use the pass-through endpoint feature to proxy requests to arbitrary internal URLs — including the AWS metadata service — and the x-pass- header-forwarding mechanism defeats IMDSv2's session-token requirement, enabling cloud IAM credential theft. (3) In September, Microsoft reported attackers chaining CVE-2026-42271 and CVE-2026-48710 (the Starlette 'BadHost' authentication bypass) to break into LiteLLM gateways and deliver an XMRig miner via an ELF binary (per The Hacker News). Attacks on exposed RAGFlow instances, meanwhile, yielded stolen LLM provider keys and metadata rather than ransomware.

Analysis (separated from facts): what these stories show is that AI gateways have moved beyond the 'LLMjacking' stage — spending someone else's API budget — to become a legitimate cloud intrusion path. LiteLLM executes server-side Python on every inference request, can proxy requests to arbitrary internal URLs, and connects to external tools via MCP. It is not merely a vault of keys; it is a bridge into the internal network with execution capability. Assets that defenders prefer to tuck away under an 'it's AI, keep it internal' design principle become, for attackers, a multi-stage path to keys, IAM, and internal APIs behind a single authentication bypass. The structural gap between defaults designed for developer experience (sk-1234, PROXY_ADMIN when unconfigured) and production deployment is worth naming as such.

Defensive implications: (1) If you run LiteLLM, first update to v1.84.0 or later (CVE-2026-59822 fix) and v1.83.7 or later (CVE-2026-42271 fix), plus Starlette 1.0.1 or later; confirm the default master key has been changed and the instance is not internet-exposed. (2) Rotate all stored provider API keys as if they were compromised the moment exposure is confirmed, and set spend limits to cap damage when a key does walk. (3) Treat features that carry arbitrary code execution or arbitrary URL proxying — MCP, pass-through endpoints — as agent-level permissions to be inventoried separately and disabled by default. (4) Audit other AI gateways and LLM orchestrators with the same lens: default credentials, exposed admin functionality, internal URL proxying. These are our analysis, not vendor guidance.

Facts in this article are drawn primarily from Wiz's research (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), BerriAI LiteLLM's fix release (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable), and the CISA KEV catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), with The Hacker News reporting as secondary (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html and https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html); the September 2 KEV date follows Wiz's timeline. The analysis sections are kept separate from the factual reporting. Note that instance counts and cloud-environment share are estimates that depend on the time and method of measurement.