On September 2, 2026, CISA added a Model Context Protocol vulnerability to its Known Exploited Vulnerabilities catalog for the first time. Five days later a second, more severe bug turned up in a different, widely-used MCP server. Neither is an exotic MCP-specific flaw — one is an authentication fallback that failed open, the other is a database privilege bypass — which is exactly the point: MCP is deployed widely enough now that ordinary bug classes in ordinary infrastructure are what takes it down.
The first MCP entry on CISA's exploited list
CVE-2026-59822 is an authentication bypass in LiteLLM, the open-source proxy a large share of self-hosted AI stacks use to route calls to models and, for many teams, to their MCP servers. CISA added it to the Known Exploited Vulnerabilities catalog on September 2, with a remediation deadline of September 16 for US federal systems — a fast clock that, under the agency's new Binding Operational Directive 26-04, is reserved for flaws that are confirmed exploited, reachable from the public internet and easy to automate. As far as we can tell, it is the first Model Context Protocol implementation to appear on that list.
How the bypass worked
LiteLLM's MCP Streamable HTTP endpoint checks the caller's key and has a fallback path for upstream OAuth2 passthrough. When key validation failed, the fallback did not deny the request — it substituted an empty UserAPIKeyAuth() object and let the call through anyway. A request carrying nothing more than a fabricated Authorization header could reach whatever MCP tools were configured, no valid key required. The fix, shipped in version 1.84.0, closes that fallback. LiteLLM published the advisory back in June; CISA's listing two months later is what confirmed the flaw was actually being used against real deployments, not just theoretically exploitable.
A second, more severe bug five days later
On September 9, AWS Labs disclosed CVE-2026-87911 in its own postgres-mcp-server: a critical, CVSS 9.6 flaw where the SQL validation behind the server's read-only mode could be defeated with a crafted COPY ... TO PROGRAM statement, letting an attacker run operating-system commands on the database host. It only bites when the MCP server connects with a role that holds superuser or pg_execute_server_program privileges — a shortcut plenty of quick setups take, because it is the path of least resistance until something reads the advisory for you. Fixed in 1.1.7.
Why this is landing on MCP specifically
Neither bug is a flaw in the MCP specification — an auth fallback that fails open and a privilege escalation via COPY TO PROGRAM are bug classes as old as the technologies underneath them. What changed is that fixing them on an accelerated clock is now worth CISA's and AWS's time, because MCP servers sit exactly where a database or API gateway does: reachable, holding credentials, and now common enough to be a target class instead of a curiosity. CISA's September 2 batch logged seven exploited flaws; three, including this one, were reported as targeting AI infrastructure specifically.
What to actually do about it
- Patch LiteLLM to 1.84.0+ and postgres-mcp-server to 1.1.7+ if you run either — both fixes are already out.
- Whatever MCP server touches a database, connect it with a role scoped to the tables and operations it actually needs, never superuser. Read-only mode is a safety net, not a substitute for database-level permissions.
- Test the failure path of your auth, not just the success path. A validator that fails open is worse than one that crashes, and from the outside they look identical until someone finds the gap.
- If you can't patch immediately, put the MCP proxy behind a gateway that can gate or rate-limit the /mcp/ routes on its own.
It also underlines the point our own OAuth checklist has been making since August: the specification requires OAuth 2.1 on every MCP server, and plenty of servers still cut that corner. These two CVEs are what cutting it costs in practice — not a hypothetical, a dated CISA catalog entry with a remediation clock attached.
