AI gateways don become di attack surface — LiteLLM KEV listing and di path through keys, MCP, and di cloud
BerriAI LiteLLM MCP authentication bypass (CVE-2026-59822) don land for CISA KEV catalog, and Microsoft report say attackers dey use LiteLLM gateways to deliver XMRig. Wiz research find roughly 1 in 10 of ~3,000 public instances accept di default key sk-1234 or run with no auth. We dey look wetin e mean say AI infrastructure na vault of credentials.
Dis article na machine translation.
For September 2026, CISA add BerriAI LiteLLM MCP authentication bypass, CVE-2026-59822, to im Known Exploited Vulnerabilities (KEV) catalog (2 September, according to Wiz timeline). Di flaw let arbitrary Bearer token establish valid authenticated session on LiteLLM MCP Streamable HTTP endpoint, and e appear alongside six other exploited flaws — including SonicWall SMA 1000 and Sangoma Switchvox — for di early-September KEV update (according to The Hacker News). LiteLLM na open-source AI gateway wey hold di API keys for every configured LLM provider; by Wiz estimate e dey present for roughly one-third of cloud environments.
Di facts: (1) Wiz research (wey dem publish 9 September) find say of roughly 3,000 internet-facing LiteLLM instances, about 9.6% accept di default master key sk-1234 or no need authentication at all. For instances without authentication configured, every user get PROXY_ADMIN by default, and reach admin functionality without credentials (e don fix since den). (2) With admin rights, attacker fit use di pass-through endpoint feature to proxy requests to arbitrary internal URLs — including di AWS metadata service — and di x-pass- header-forwarding mechanism defeat IMDSv2 session-token requirement, wey enable cloud IAM credential theft. (3) For September, Microsoft report say attackers dey chain CVE-2026-42271 and CVE-2026-48710 (di Starlette BadHost authentication bypass) to break into LiteLLM gateways and deliver XMRig miner through ELF binary (according to The Hacker News). Attacks on exposed RAGFlow instances, for anoda side, yield stolen LLM provider keys and metadata rather than ransomware.
Analysis (wey we separate from facts): wetin dese stories show na say AI gateways don move past di LLMjacking stage — to spend somebody else API budget — to become real cloud intrusion path. LiteLLM dey execute server-side Python on every inference request, fit proxy requests to arbitrary internal URLs, and connect to external tools through MCP. E no be only vault of keys; e na bridge into di internal network with execution capability. Assets wey defenders prefer to tuck away under design principle «na AI, keep am internal» become, for attackers, multi-stage path to keys, IAM, and internal APIs behind single authentication bypass. Di structural gap between defaults wey dem design for developer experience (sk-1234, PROXY_ADMIN when e no dey configured) and production deployment worth to name as such.
Wetin e mean for defense: (1) If you dey 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 say di default master key don change and di instance no dey internet-exposed. (2) Rotate all stored provider API keys as if dem don compromise di moment exposure dey confirmed, and set spend limits to cap damage when key walk. (3) Treat features wey carry arbitrary code execution or arbitrary URL proxying — MCP, pass-through endpoints — as agent-level permissions to inventory separately and disable by default. (4) Audit other AI gateways and LLM orchestrators with di same lens: default credentials, exposed admin functionality, internal URL proxying. Dese na our analysis, no be vendor guidance.
Facts for dis article draw mainly from Wiz research (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), BerriAI LiteLLM fix release (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable), and di 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); di 2 September KEV date follow Wiz timeline. Di analysis sections dey kept separate from di factual reporting. Note say instance counts and cloud-environment share na estimates wey depend on di time and method of measurement.