European teams that chose to self-host LiteLLM specifically to keep AI traffic and data residency inside their own infrastructure have a second, unrelated vulnerability to close this week, this time in the access control layer they were relying on to enforce that boundary.
An empty auth object that still says yes
CVE-2026-59822 sits in LiteLLM’s Model Context Protocol (MCP) Streamable HTTP endpoint, the interface that lets AI agents call out to external tools. Prior to version 1.84.0, sending a fabricated Authorization header with an arbitrary Bearer token triggered an OAuth2 passthrough fallback path. When that path’s key validation failed, instead of rejecting the request, LiteLLM substituted an empty UserAPIKeyAuth() object and let the request continue through to MCP tooling anyway. In practice, an attacker who knew nothing about the environment could hand it a made-up token and reach the same MCP tools a legitimate authenticated caller would reach. The flaw carries a CVSS score of 8.8, and it is fixed in version 1.84.0.
Not the same incident you may already have patched for
If your team ran an incident review on LiteLLM back in August over the Trivy-linked supply chain compromise that shipped credential-stealing code through PyPI, this is a different bug entirely: no malicious package, no CI/CD pipeline poisoning, just a logic flaw in how the gateway itself decides whether to trust an incoming request. Patching the earlier supply chain incident does nothing for this one, and vice versa. Both need to be tracked and closed independently.
Why the MCP endpoint specifically matters
MCP is the interface AI agents use to reach outside their own sandbox and call real tools, databases, file systems, internal APIs, anything an organisation has wired up. A gateway that is supposed to gate access to those tools but can be talked into an authenticated session with a fake token is not a minor access control gap, it is the exact control that was meant to stand between an AI agent and whatever it has been given permission to touch. CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities catalog on September 2, alongside CVE-2026-48710 in Starlette, LiteLLM’s own underlying framework, giving federal agencies until September 16 to remediate. Both vulnerabilities were confirmed under active exploitation on the same day, which is a reasonable signal that anyone running LiteLLM in production should treat this week as a priority patch cycle, not a routine one.
What to do now
Upgrade to LiteLLM 1.84.0 or later, then audit MCP endpoint logs for Bearer tokens that do not correspond to any key you issued, since that is the specific signature of this bypass having been attempted. If you run LiteLLM as a shared gateway across multiple teams or products, treat every MCP tool it fronts as having been reachable by an unauthenticated caller until you confirm the patch is deployed everywhere, not just on the instance you remembered to check first.
If you need help auditing your AI gateway deployments, verifying which of your services were exposed, or designing an access control architecture for agentic AI tooling that does not depend on a single gateway getting every edge case right, contact Excello Digital. We help European organisations build AI infrastructure that holds up under exactly this kind of scrutiny.