Exploited LiteLLM flaw exposes connected tools

An older flaw has a new exploitation signal

On 2 September, the US Cybersecurity and Infrastructure Security Agency added CVE-2026-59822 to its Known Exploited Vulnerabilities catalogue. CISA describes an improper-authentication flaw in LiteLLM's MCP Streamable HTTP endpoint which can let an unauthenticated attacker establish an authenticated MCP session using an arbitrary bearer token. Inclusion in the catalogue means CISA has evidence of exploitation in the wild. It records ransomware use as unknown; that is not evidence either way.

The vendor advisory was published on 30 June, so the vulnerability itself is not new. The current development is CISA's exploitation finding. The agency's 16 September remediation deadline applies to relevant US federal bodies, not UK companies, but the catalogue entry is a useful prioritisation signal for any organisation running the affected component.

Why the gateway's connections define the consequence

BerriAI says LiteLLM versions before 1.84.0 are affected. In the vulnerable authentication path, a failed LiteLLM key check could fall back to an empty authenticated-user object. A fabricated authorisation header could then reach the gateway's MCP functions without a valid LiteLLM key. The vendor says an attacker could list and call configured MCP tools and access services exposed through those connections.

That makes the practical impact deployment-specific. One gateway may expose a narrow read-only tool; another may connect to business systems with permission to retrieve data or make changes. Do not reduce the assessment to whether the LiteLLM service held sensitive data itself. Establish which MCP servers and tools were configured, what identities and credentials they used, which networks could reach the endpoint, and what records exist across the gateway and downstream services.

The sources confirm exploitation of the vulnerability, not that every affected installation has been compromised. They also do not establish how exploitation occurred in any particular environment. Keep the review evidence-led and avoid assuming that a private address or reverse proxy removed exposure without checking its actual routing and access rules.

Update, contain and review

Inventory LiteLLM services in development, production, shared AI platforms and supplier-managed environments. Confirm the running package or container version rather than relying on a deployment file that may be stale. BerriAI identifies 1.84.0 as the fixed version and recommends upgrading to that release or later. Test the current supported release against your configuration because the 1.84.0 release carries a breaking-change notice.

If an immediate update is not possible, the vendor recommends disabling MCP routes or blocking access to the MCP endpoints at the reverse proxy or API gateway. Treat that as temporary containment, document it, and verify from an authorised path that the restriction works. It does not determine whether earlier access occurred.

For an affected gateway that was reachable, preserve relevant authentication, request, tool-call and downstream-service logs before routine retention removes them. Review unexpected MCP sessions and tool activity, then assess any credentials or connected services that may have been accessible. Rotate or revoke credentials when the evidence or your incident process warrants it, coordinating changes so that useful records are not lost.

• Locate LiteLLM services and confirm their running versions.
• Update affected installations to 1.84.0 or a later supported release.
• Temporarily disable or block MCP routes where an update cannot yet be made.
• Map each gateway to its configured tools, identities and reachable services.
• Preserve and review evidence proportionately where an affected endpoint was reachable.

The Beekeeper view

An AI gateway is a security boundary, not merely plumbing between models and tools. Its value comes from connecting systems and carrying authority across those connections; the same properties determine the blast radius when authentication fails.

Patch the known flaw, but close the task only after the deployment has an owner, its MCP reach is understood and unnecessary access has been removed. The useful question is not simply whether LiteLLM was exposed. It is what an unauthorised LiteLLM session could have asked the connected estate to do.