ZeroDayAlert

CVE-2026-59822: BerriAI LiteLLM Improper Authentication Vulnerability

BerriAI LiteLLM contains an improper authentication vulnerability in the MCP Streamable HTTP endpoint that could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.

BerriAI LiteLLM Added to KEV 2026-09-02 Federal due 2026-09-16 Known ransomware use

Required action — quoted from CISA

Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Where this comes from. The identifier, product, dates and required action above are copied verbatim from the CISA Known Exploited Vulnerabilities catalog. The action plan below is written by an AI agent from that record and published automatically. AssurePort has not independently tested this vulnerability and makes no claim about whether any specific system is affected.

Who is affected

BerriAI LiteLLM is affected by an improper authentication flaw in its MCP Streamable HTTP endpoint. The vulnerability allows an unauthenticated attacker to forge an authenticated session using an arbitrary Bearer token. The record does not specify which versions of LiteLLM are vulnerable, nor does it detail deployment contexts beyond the HTTP endpoint itself.

How to check whether this touches you

  • Inventory whether you run BerriAI LiteLLM in your infrastructure or as a third-party service dependency.
  • Confirm whether the MCP Streamable HTTP endpoint is reachable from untrusted networks, including the internet or other tenant boundaries.
  • Check your LiteLLM logs for Bearer token patterns in requests to the MCP Streamable endpoint; successful exploitation will show authenticated sessions initiated without legitimate credential exchange.
  • Query your network telemetry for HTTP requests to the MCP endpoint that carry Bearer tokens you did not issue; this may indicate reconnaissance or exploitation attempts.
  • Contact your LiteLLM vendor or systems owner to confirm whether patches or mitigations are available and whether your running version contains the flaw.

What to do

  1. Immediately apply vendor-supplied patches or mitigations according to BerriAI's published instructions. If none are available, escalate to your change advisory board and security leadership for discontinuation or isolation decisions.
  2. If you cannot patch immediately, restrict network access to the MCP Streamable HTTP endpoint to trusted internal hosts only; use firewall rules or API gateway policies to block external connections.
  3. Enable comprehensive logging of all HTTP requests to the MCP endpoint, including request headers, Bearer tokens (redacted for security logs), response codes, and source IP addresses. Retain these logs for the period specified in your organisation's forensics retention policy.
  4. Notify your incident response and security operations teams that exploitation may have occurred prior to this advisory. Prepare to conduct log-based investigation if indicators emerge.
  5. Follow CISA's BOD 26-04 guidance on patching timelines and escalate to your risk owner if you cannot meet the federal remediation due date.

If you find you were exposed

Exploitation of authentication bypasses typically precedes public disclosure by weeks or months, so you should search your MCP endpoint logs retrospectively for Bearer tokens that do not correspond to known, authorised integrations. Focus your hunt on the period from your deployment date to the present. Cross-reference suspicious tokens with your identity and access management records to identify whether legitimate credentials could have generated them. Log retention is often the limiting factor; if your logs have rotated or been deleted, document the gap and use this incident to justify longer retention policies for sensitive endpoints going forward.

Get these the morning they land.

One email, only when a vulnerability is newly confirmed as exploited — the CISA record plus our action plan. No more than one a day, and nothing on quiet days.

Knowing it exists is not the same as knowing you are exposed.

This page can tell you that CVE-2026-59822 is being exploited. It cannot tell you whether LiteLLM is running somewhere of yours that is reachable. That question is what a scan answers.

Check your own surface →