Build1 publisher2 min readPublished
LiteLLM's MCP endpoint answered a failed key check with an empty auth object
CVE-2026-59822 is fixed in LiteLLM 1.84.0 and has been on CISA's exploited list since September 2. A ZoomEye scan two weeks later fingerprinted 33,005 internet-reachable LiteLLM assets, a count of how widely the proxy is deployed.
The Engineer · Build desk
What happened
- CVE-2026-59822, an authentication bypass in LiteLLM's MCP Streamable HTTP endpoint, was fixed in version 1.84.0 and added to CISA's Known Exploited Vulnerabilities catalog on 2026-09-02.
- A ZoomEye search for the product fingerprint app="LiteLLM" returned 33,005 matching assets when it was run on 2026-09-16 across the engine's full scope.
- A second query scoped to the CVE itself returned zero results, which the author puts down to indexing lag and to fingerprints that name a product without linking it to an advisory.
- Wiz and Microsoft published research in September 2026 on campaigns that chained the bypass with MCP test-endpoint command injection and a host-header flaw to reach code execution, activity researchers tied to Qilin.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure The check that failed open guards a host holding the upstream provider keys and brokering tool calls into databases and repositories. An unauthenticated request arrives beside the credential material.
- cost Patching does not close the incident: provider keys and the virtual keys the proxy issued become rotation candidates, and that work lands on every internal caller, not on the team that applied the upgrade.
- constraint An external scan cannot tell an owner which of their instances actually exposes the MCP endpoint or already sits behind a second authentication layer. Prioritization has to come from an internal inventory that includes gateways platform and data-science teams stood up themselves.
- decision Teams that cannot ship 1.84.0 in this window are choosing between turning the MCP Streamable HTTP endpoint off and moving Authorization validation into the reverse proxy. Leaving it as-is is now a decision taken against a KEV entry.
The defect is a default value standing where a rejection belongs. When the LiteLLM key check failed on the MCP Streamable HTTP endpoint, the code substituted an empty `UserAPIKeyAuth()` object and continued, so a forged `Authorization` header was treated as authenticated [2]. An unauthenticated caller reached the configured MCP tools [3].
That matters because of where the proxy sits. LiteLLM fronts several model providers through one interface, which means it 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 [4].
The exposure figure needs reading carefully before it goes into anyone's risk register. It is a ZoomEye product fingerprint for `app="LiteLLM"`, collected on 2026-09-16, 14 days after the KEV entry [5][1]. The writeup is explicit about what stays open after the scan: the version each instance runs, whether MCP is enabled at all, whether a second authentication layer would stop a forged header before it reaches the application, whether anything has already been accessed [7]. For 33,005 to mean 33,005 reachable bypasses, all four of those would have to break the wrong way on every instance. What the number does support, according to the author, is scale: a gateway with tens of thousands of public fingerprints is a shared dependency [9].
The more instructive result came from the companion query. A search scoped to `vul.cve="CVE-2026-59822"` returned 0, and the author attributes that to CVE indexing lagging disclosure and to fingerprinting that identifies a product without tying it to an advisory [8].
I would copy the remediation order in the writeup. Upgrade to 1.84.0 or later; where that is not immediately possible, disable the MCP Streamable HTTP endpoint and enforce `Authorization` validation at the reverse proxy [13]. 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 [11]. Then constrain what the gateway's own identity can reach, which the author raises specifically for proxies running with broad cloud permissions and able to contact a metadata endpoint [12].
What to watch
- Whether ZoomEye's CVE-scoped index catches up and starts attributing some of the LiteLLM fingerprints to CVE-2026-59822.
- Whether Wiz or Microsoft publishes version-level detail or indicators tying the Qilin activity to specific LiteLLM releases.
- Whether LiteLLM changes the default so that on any endpoint a failed key check rejects the request and no auth object gets constructed.