33,005 Internet-Reachable LiteLLM Gateways: Measuring the AI Gateway Attack Surface After CVE-2026-59822

CVE-2026-59822 is an authentication bypass in LiteLLM's MCP Streamable HTTP endpoint, fixed in version 1.84.0 and added to CISA's Known Exploited Vulnerabilities catalog on 2026-09-02. The vulnerability itself is a code defect. The reason it deserves a measurement exercise is that LiteLLM is usually deployed as a shared gateway that holds provider credentials and brokers tools — so the number of instances reachable from the public internet is a useful proxy for how much credential material sits behind a single authentication check.

What was measured

A ZoomEye search for the product fingerprint app="LiteLLM" returned 33,005 matching assets at the time of collection (2026-09-16, scope all). This is a product-exposure count: it describes assets that ZoomEye fingerprints as LiteLLM, not assets confirmed to be running a vulnerable version or confirmed to be compromised. It is a starting point for prioritization, not a verdict.
A separate CVE-scoped query, vul.cve="CVE-2026-59822", returned 0. That result is expected and should not be read as reassurance. CVE indexing in cyberspace search engines lags disclosure, and many fingerprinting methods identify the product without tying it to a specific advisory. The absence of a CVE-indexed result means the search engine has not associated those assets with this CVE; it does not mean the assets are patched.

How to read the number

The 33,005 figure is a count of internet-facing LiteLLM instances. It does not tell you:

• which version each instance runs;
• whether MCP is enabled (the bypass only matters on the MCP Streamable HTTP endpoint);
• whether the instance is behind an additional authentication layer that would stop a forged header before it reaches the application;
• whether any instance has already been accessed. Those are questions for the asset owner, not for a search engine. What the count does establish is scale: this is not a niche component. A gateway product with tens of thousands of public fingerprints is a shared dependency, and shared dependencies concentrate risk. ## Why the gateway position matters LiteLLM is a proxy that lets applications call multiple model providers through one interface. In practice that means the proxy holds the upstream provider API keys, issues virtual keys to internal callers, and — since MCP support was added — brokers calls to tools that may reach databases, repositories, and internal APIs. The MCP Streamable HTTP endpoint is the part affected by CVE-2026-59822. The vulnerable behavior was a fail-open fallback: when a LiteLLM key check failed on that endpoint, the code substituted an empty UserAPIKeyAuth() object instead of rejecting the request, so a forged Authorization header could be treated as authenticated. That is what let an unauthenticated caller reach the configured MCP tools. Independent research published in September 2026 by Wiz and by Microsoft described campaigns against internet-reachable AI infrastructure, including LiteLLM gateways and MCP servers. The reported chains combined the MCP authentication bypass with a command-injection flaw in MCP test endpoints and a host-header handling issue to reach code execution, and researchers linked the activity to the Qilin ransomware group. Those campaign details are third-party findings; the durable point is that attackers are treating AI gateways as entry points rather than as tooling. ## Turning the measurement into action For an organization that runs LiteLLM, the useful workflow is:
• Identify every LiteLLM instance, including ones stood up by platform or data-science teams outside the central asset register. Public fingerprints are a good cross-check against your own inventory.
• Determine which instances are reachable from the internet and which expose the MCP Streamable HTTP endpoint. The bypass is specific to that endpoint.
• Upgrade to 1.84.0 or later. If that is not immediately possible, disable the MCP Streamable HTTP endpoint and enforce Authorization validation at the reverse proxy.
• If an instance was publicly reachable and unpatched, treat credential rotation as part of the response — and investigate the host first, because reported activity included recovering the proxy master key from process memory rather than from disk.
• Restrict what the gateway's own identity can reach. If the proxy runs with broad cloud permissions and can contact a metadata endpoint, an authentication bypass becomes a path to cloud credentials. ## What ZoomEye adds here The value of an exposure query in this case is not the headline number. It is the ability to compare a product fingerprint against your own records and to see whether the component you assumed was internal has public fingerprints at all. For AI infrastructure specifically, that check is often the first time the component appears in a security conversation. A search engine can tell you the component is exposed; only the owner can tell you whether it is patched, whether MCP is enabled, and whether anything reached it. ## References
• ZoomEye exposure query app="LiteLLM", scope all, count 33,005, collected 2026-09-16.
• ZoomEye query vul.cve="CVE-2026-59822", count 0, collected 2026-09-16.
• LiteLLM GitHub Security Advisory GHSA-7488-6r32-c95q (CVE-2026-59822), fixed in 1.84.0.
• CISA, "CISA Adds Seven Known Exploited Vulnerabilities to Catalog," 2026-09-02.
• Wiz Research, "Off Guard: Breaking LiteLLM — From Authentication Bypass to Cloud Compromise," 2026-09-09.
• Microsoft security research on AI infrastructure targeting, September 2026 (as summarized in industry reporting).