LiteLLM CVE-2026-59822 on CISA KEV: Patch and Audit Steps

Image: Unsplash.

Use this if your team runs a LiteLLM proxy, or any Python service built on FastAPI or Starlette that's reachable from outside your laptop. On September 2, 2026, CISA added seven flaws to its Known Exploited Vulnerabilities (KEV) catalog. Two of them sit in the AI stack small teams run themselves: CVE-2026-59822 in LiteLLM and CVE-2026-48710, nicknamed BadHost, in Starlette.

Correction, October 15, 2026: the September version said attackers chained BadHost with CVE-2026-59822 to take over LiteLLM gateways. CISA's catalog, Horizon3.ai and Microsoft tie BadHost to a different LiteLLM flaw, CVE-2026-42271, which was already on the KEV list from June 8. The Starlette range, the disclosure gap, and the Qilin and XMRig attributions are fixed below, and an unsourced line about why CISA set a later deadline is removed.

What CISA listed, and why it matters to an AI gateway

The other five entries in the September batch (SonicWall SMA1000, Sangoma Switchvox, JFrog Artifactory, Kestra) were due on September 5.

The MCP bypass. LiteLLM's MCP endpoint is what lets the gateway hand tools, like a database connector, to connected agents. The GitLab advisory explains that when LiteLLM's key check failed, an OAuth2 passthrough fallback "could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object." Any made-up Authorization header then reached MCP tooling. It's rated 8.2 on CVSS v3.1 and 8.8 on CVSS v4.0. Wiz, which found it, says the fix shipped in 1.84.0 in April, it saw exploitation in its honeypots on July 7, and the CVE was published on July 8, about eight weeks before the KEV listing.

Screenshot: CVE-2026-59822 advisory, GitLab Advisory Database.

BadHost. Starlette, the framework under FastAPI, vLLM and LiteLLM, didn't validate the Host header before rebuilding request.url. Routing uses the raw path while many auth checks read the rebuilt one, so a crafted Host header can slip past path-based checks. A senior researcher at X41 D-Sec found it during an OSTIF-managed audit of vLLM sponsored by the Alpha-Omega Project. Every Starlette version before 1.0.1 is affected; the CVSS v3.1 score is 6.5.

When BadHost was disclosed in May, the Hacker News thread split on how worried to be. The user ostif-derek wrote that "Rating it a medium understates how hard it hits thousands of downstream projects and billions of installs," and blamed poor patch rates partly on that rating. Another commenter, noirscape, wrote that a reverse proxy routing by server name "should be stopping this attack at the door," unless all traffic falls through a default server rule. Both points shape step 4 below: a proxy in front helps, but only if it rejects Host headers it doesn't know.

The chain that's being exploited. CISA's KEV entry for BadHost says it "could be chaned [sic] with CVE-2026-42271." Horizon3.ai showed the pair gives unauthenticated remote code execution on LiteLLM. Microsoft reported attackers using that pair to drop an XMRig miner, read LiteLLM's proxy tables for upstream provider keys and virtual keys, and persist by editing ~/.ssh/authorized_keys. Wiz linked actors associated with the Qilin ransomware group to exploitation of the same chain. CVE-2026-59822 is a separate route in, and Wiz saw it used to probe model enumeration endpoints.

Wiz also found that "Nearly 1 in 10 publicly accessible LiteLLM instances accept a default master key or require no authentication at all," out of roughly 3,000 it scanned. The Docker compose and pip installs still set the master key to sk-1234. Those deployments don't need any CVE.

Screenshot: "Off Guard: Breaking LiteLLM", Wiz Research.

Steps, in order

Run these whether or not a federal directive binds you. CISA's newer directive, BOD 26-04, makes the point that patching alone doesn't evict an attacker who got in first, so the checks after the upgrade matter as much as the upgrade.

1. Find every LiteLLM and Starlette install. Starlette usually arrives as a dependency of FastAPI, so read the lockfile or pip show starlette inside each running image, not just your top-level requirements.
2. Upgrade LiteLLM to 1.84.0 or later and Starlette to 1.0.1 or later. Rebuild and redeploy every image and virtualenv that pins or bundles them; a changed manifest isn't a patched container.
3. Replace the master key. If it's sk-1234, empty, or copied from the docs, set a long random key and store it in your secrets manager.
4. Take the MCP endpoint off the open internet unless something outside needs it. Put it behind a VPN or an IP allowlist.
5. Check for persistence. On every host that ran an unpatched gateway, compare ~/.ssh/authorized_keys against the keys you issued and look at the file's change time.
6. Look for miners and odd egress. XMRig was the payload Microsoft reported. Unexplained CPU load or outbound connections from the gateway host need a look before you call it clean.
7. Rotate every credential the gateway could read. That's the upstream model provider keys, LiteLLM virtual keys, the master key, and the database credentials behind the proxy's tables. If you can't rule out access, rotate.
8. Restrict egress and IAM. Give the gateway only the outbound routes and cloud permissions it needs, so the next bypass reaches less.

Image: Unsplash.

What to log or keep

• The LiteLLM and Starlette versions on each host before and after, with the date you redeployed.
• Which keys you rotated and when, so a later bill or abuse report can be matched to the window.
• What you found in authorized_keys, process lists and egress logs, even if it was nothing.
• A line in your vendor or dependency register for LiteLLM. Its own record this year includes the March PyPI compromise, CVE-2026-42271 and CVE-2026-59822, so give it a review date rather than treating it as plumbing.

Screenshot: Responsible disclosure timeline, "Off Guard: Breaking LiteLLM", Wiz Research.

Not the same as the March breach

In March 2026, the group tracked as TeamPCP compromised Trivy, the container scanner, and used credentials stolen through it to publish two malicious LiteLLM releases to PyPI. The campaign is CVE-2026-33634: the CVE record lists the Trivy components and LiteLLM 1.82.7 and 1.82.8 as affected, and CISA added it to KEV on March 26, 2026. Our LiteLLM supply chain breach checklist covers it. CVE-2026-59822 is unrelated: a flaw in LiteLLM's own MCP code. If your MCP governance only covers which tools an agent may call, add who can authenticate to reach them; our MCP server governance checklist has both.

What we could not confirm: CISA's own pages refused our requests, so the KEV dates and descriptions here come from CISA's official KEV data feed on GitHub and from The Hacker News' report of the alert. We also couldn't find which LiteLLM version fixed CVE-2026-42271; check the LiteLLM advisory linked from the KEV entry. There's no video here: the YouTube explainers on these CVEs come from small channels, not from the researchers or CISA.

Related Reading

• CISA AI token guidance: a denial-of-wallet playbook
• LiteLLM 1.107.0 malware: what to check and which keys to rotate
• MCP Server Security: Governance Checklist for Small Teams
• LiteLLM Supply Chain Breach: 7-Point Vendor Audit Checklist
• AI Red Teaming: Security Testing Requirements for 2026
• Vetting AI Tools: Fake Malware and Typosquatting Risks
• TypeScript AI Agent Security: Incident Response Playbook
• AI Support Chatbot Account Takeover Risk

Sources: CISA KEV catalog data (cisagov/kev-data), The Hacker News: CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners, GitLab Advisory Database: CVE-2026-59822, GitLab Advisory Database: CVE-2026-48710, OSTIF: Disclosing the BadHost Vulnerability in Starlette, Wiz: Off Guard, Breaking LiteLLM, Tenable: CVE-2026-59822, NVD: CVE-2026-33634, The Hacker News: Malicious LiteLLM Releases Tied to Trivy Hack, Industrial Cyber: CISA BOD 26-04