TL;DR: On September 2, 2026, CISA added seven vulnerabilities to its Known Exploited Vulnerabilities catalog, and three target AI infrastructure directly. The headline addition is CVE-2026-59822, an authentication bypass in LiteLLM's Model Context Protocol endpoint that lets an attacker forge a Bearer token and skip key validation entirely. Attackers are already chaining it with a separate Starlette framework flaw, CVE-2026-48710 (nicknamed BadHost), to gain remote code execution against LiteLLM gateways, then stealing database credentials, model provider API keys, and verification tokens before planting SSH backdoors. The September 16, 2026 federal patch deadline has passed. If your team runs LiteLLM, FastAPI, vLLM, or any self-hosted MCP server and has not yet patched, the exploit chain remains active.
Most CISA Known Exploited Vulnerabilities additions pass without notice outside security teams. This one is different. Of the seven flaws CISA added on September 2, 2026, three sit directly in the AI infrastructure stack that small teams increasingly run themselves: an AI gateway, the web framework underneath it, and an artifact repository used in ML pipelines. This is reportedly the first time a Model Context Protocol implementation has landed on the KEV list, and the exploitation researchers are already tracking gives a clear preview of what "AI infrastructure attack surface" looks like once attackers start treating it as a normal target instead of a novelty.
What CISA added on September 2
The batch of seven covers a SonicWall SMA 1000 pair, a Sangoma Switchvox SQL injection flaw, a JFrog Artifactory authentication bypass, an OS command injection bug in the workflow tool Kestra, and the two that matter most for AI teams: CVE-2026-59822 in LiteLLM and CVE-2026-48710 in Starlette, the ASGI framework that underlies FastAPI, vLLM, LiteLLM, and a wide swath of self-hosted MCP servers.
Five of the seven carry a September 5, 2026 federal remediation deadline. The Starlette and LiteLLM pair got a longer runway, due September 16, 2026, but that is not because they are less serious. It is because researchers found them being exploited together, and CISA's own guidance now treats coordinated exploit chains differently than single opportunistic bugs.
Inside CVE-2026-59822: how the MCP bypass works
LiteLLM is the open-source AI gateway that a large share of small teams use to route calls across OpenAI, Anthropic, Gemini, and self-hosted models through one proxy, track spend, and standardize failover. Its Model Context Protocol endpoint is what lets that gateway expose tools, like a database connector or a Slack integration, to connected AI agents.
The bug, tracked as CWE-287 (improper authentication), lives in how that endpoint handles failed key checks. When a request's Bearer token fails LiteLLM's normal validation, a fallback path in the OAuth2 passthrough logic was supposed to reject it. Instead, according to the GitLab Advisory Database, the fallback quietly replaced the failed validation with an empty UserAPIKeyAuth() object, effectively granting access anyway. An attacker only needs to send any fabricated Authorization header to the MCP Streamable HTTP endpoint to establish a session as if they had a real key.
The vulnerability affects every LiteLLM version before 1.84.0 and was fixed in that release. It carries a CVSS v3.1 score of 8.2 and a CVSS v4.0 score of 8.8, both rated high. It was publicly disclosed on July 8, 2026, roughly seven weeks before CISA confirmed active exploitation and added it to the KEV catalog.
The real attack chain: BadHost plus the MCP bypass
An authentication bypass is bad on its own. What made this pair urgent enough for a KEV listing is how cleanly they combine.
CVE-2026-48710, nicknamed BadHost by the researchers who found it, is a separate flaw in Starlette itself. It was discovered by the security firm X41 D-Sec during an audit of vLLM sponsored by the Open Source Technology Improvement Fund. Starlette failed to validate the HTTP Host header before using it to reconstruct request.url. Because routing decisions rely on the raw request path while security middleware often checks request.url instead, a single malformed character in the Host header can make those two views of the request disagree, letting an unauthenticated attacker slip past path-based security checks entirely. It affects Starlette 0.8.3 through 1.0.0 and is fixed in 1.0.1. Its CVSS score is a comparatively modest 6.5, which researchers say understates the real-world impact given how many AI frameworks sit on top of Starlette.
According to reporting from The Hacker News, attackers chained the two: use BadHost to slip past the path-based check guarding an endpoint, then use the LiteLLM MCP bypass to establish an authenticated-looking session once inside. From there, the reported impact includes theft of database credentials and configuration records, LLM provider API keys and endpoint details, verification tokens from LiteLLM's proxy tables, and in some cases direct access to the backend Postgres tier. Attackers reportedly established persistence by modifying ~/.ssh/authorized_keys and set up command-and-control channels back into the compromised gateway.
Separately, Wiz researchers found that nearly one in ten public LiteLLM instances they scanned were running with default credentials or no authentication configured at all, meaning some deployments do not even need the CVE-2026-59822 bypass to be compromised. A weak or default master key gets you there just as fast.
Not the same story as March, but the same vendor twice in five months
If LiteLLM sounds familiar, it should. In March 2026, the group tracked as TeamPCP hijacked a CI pipeline and shipped malicious LiteLLM packages through PyPI, a breach tracked as CVE-2026-33634 that exposed more than 2,400 organizations, including a 4TB data loss at the AI training startup Mercor. That was a supply chain compromise of LiteLLM's build process. CVE-2026-59822 is unrelated: a flaw in LiteLLM's own MCP authentication code, found and fixed independently of the March incident.
There is a third LiteLLM CVE in the mix too. Wiz has linked a different flaw, CVE-2026-42271, to active exploitation by threat actors associated with the Qilin ransomware group, who used it to deploy XMRig cryptocurrency miners via ELF binaries dropped through compromised gateways. That CVE is not part of the September 2 KEV batch and was already patched earlier, but it points to a pattern: LiteLLM has now had three distinct, unrelated security incidents draw active exploitation within roughly five months. For a vendor risk register, "how many CVEs has this dependency had this year" is turning into a question worth tracking on its own line.
The governance shift behind the September 16 deadline
CISA's KEV catalog has run on the same basic model for years: confirm exploitation, add the CVE, set a remediation deadline under Binding Operational Directive 22-01. What changed this year is the framework agencies use to prioritize which of those deadlines get treated as emergencies.
In June 2026, CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," which moved federal agencies away from treating every KEV addition the same way. The directive scores vulnerabilities against four criteria: whether the affected asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation can be automated, and how much technical impact a successful attack achieves. Vulnerabilities that clear all four get a three-day patch mandate. The directive also pushes agencies toward an "assume compromise and verify" posture rather than patch-and-move-on, on the reasoning that if a bug has already been exploited in the wild, patching alone does not evict an attacker who got in before the patch was applied.
That second point matters more than the calendar date. If your team runs LiteLLM and only just heard about CVE-2026-59822, patching to 1.84.0 closes the door, but it does not tell you whether someone already walked through it. The self-audit below starts with verification for that reason, not just version numbers.
A self-audit checklist for small AI teams
Run this whether or not your organization is bound by any federal directive. The exploit chain does not check your org chart before it runs.
- Confirm your LiteLLM version. Anything before 1.84.0 is vulnerable to CVE-2026-59822. Upgrade immediately, and confirm the upgrade actually rebuilt your container image rather than just updating a manifest.
- Confirm your Starlette version, even if you never installed it directly. Starlette ships as a transitive dependency under FastAPI and does not always show up in a dependency inventory. Check your lockfile, not just your top-level requirements file. Anything between 0.8.3 and 1.0.0 needs the 1.0.1 upgrade.
- Check for unauthorized SSH access. Review
~/.ssh/authorized_keyson every host running LiteLLM for entries you cannot account for, and check.sshmodification timestamps against your patch history. - Look for unexpected processes and outbound connections. XMRig and similar miners are the reported payload in related LiteLLM exploitation. Unexplained CPU load or unfamiliar outbound connections from a gateway host are worth investigating before you assume a clean patch fixed everything.
- Rotate every credential the gateway could see. That includes upstream model provider API keys, the LiteLLM master key itself, and database credentials for whatever backs the proxy's verification and model tables. If you cannot rule out compromise, rotation is cheaper than the alternative.
- Set a real master key. Wiz found nearly one in ten public LiteLLM instances running on default or no authentication. If yours uses the documentation example key or none at all, that is a separate, easier path in regardless of these CVEs.
- Restrict MCP endpoint exposure. If your MCP server does not need to be reachable from the open internet, put it behind a VPN or an allowlist. Reduce what an unauthenticated bypass can actually reach.
- Review egress rules on the gateway's network. Least-privilege IAM roles and restricted outbound network access limit what an attacker can do even if authentication is bypassed again by a future bug.
The pattern worth tracking
Three of seven KEV additions targeting AI infrastructure in a single batch is not a coincidence of timing. It reflects where attackers are actually spending effort: not against the models themselves, which are hard to compromise directly, but against the gateways, frameworks, and protocol servers that sit in front of them and that most small teams treat as plumbing rather than attack surface. An MCP server governance checklist that only covers what tools an agent can call, without covering who can authenticate to reach it, misses exactly the class of bug that made this KEV batch newsworthy.
The uncomfortable part for small teams is that this infrastructure is usually the least-reviewed part of an AI stack. Model selection gets a governance conversation. Data retention gets a policy. The open-source gateway routing every call to that model rarely gets the same scrutiny, until CISA puts it on a list with a deadline attached.
Related Reading
- 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: Adds Seven Known Exploited Vulnerabilities to Catalog (Sept 2, 2026), 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: Breaking LiteLLM, From Authentication Bypass to Cloud Compromise, Tenable: CVE-2026-59822, Industrial Cyber: CISA BOD 26-04 Directs Agencies to Prioritize Exploited Vulnerabilities
