CVE-2026-59822: BerriAI LiteLLM MCP Authentication Bypass — Detection and Remediation Guide

On September 2, 2026, CISA added CVE-2026-59822 to its Known Exploited Vulnerabilities (KEV) catalog, confirming that an improper authentication flaw in BerriAI LiteLLM is being actively exploited in the wild. This is not a theoretical risk — threat actors are already abusing this weakness against exposed LiteLLM deployments.

LiteLLM sits in a uniquely dangerous position in modern enterprise architecture. It is one of the most widely deployed open-source LLM gateways and proxies, used to broker API calls to OpenAI, Anthropic, Azure OpenAI, and dozens of other model providers. That means a typical LiteLLM instance holds the crown jewels of an AI program: provider API keys, virtual keys for internal teams, model spend controls, and — critically — Model Context Protocol (MCP) connections to internal tools and data sources.

The vulnerability lives in LiteLLM's MCP Streamable HTTP endpoint. An unauthenticated remote attacker can supply an arbitrary Bearer token and have the server establish an authenticated MCP session anyway. Once that session exists, the attacker inherits whatever tool access, data connectors, and downstream permissions the MCP server was configured with — file systems, databases, internal APIs, SaaS integrations. In an environment where MCP servers are wired into production data, this is functionally equivalent to handing an unauthenticated internet user a service account.

If you run LiteLLM anywhere in your stack — as an AI gateway, a proxy for developer tooling, or an MCP host — treat this as an emergency change window, not a routine patch.

Technical Analysis

What is affected

• Product: BerriAI LiteLLM (open-source LLM proxy/gateway and MCP host)
• Component: MCP Streamable HTTP transport endpoint
• Deployment models at risk: Self-hosted LiteLLM proxy containers, Kubernetes-hosted gateways, pip-installed instances, and any LiteLLM deployment exposing the MCP Streamable HTTP endpoint to a network an attacker can reach
• Vulnerability class: CWE-287 (Improper Authentication) — authentication bypass via arbitrary token acceptance

LiteLLM's MCP gateway functionality exposes a Streamable HTTP endpoint (the modern successor to MCP's HTTP+SSE transport, typically served under /mcp or a configured MCP path on the proxy). The endpoint is intended to negotiate authenticated sessions between MCP clients and the tools registered with the proxy.

How the vulnerability works

The Streamable HTTP transport in MCP relies on a session establishment handshake. In a correct implementation, the server validates the client's Bearer token against configured credentials or an upstream identity provider before creating a session and returning a session identifier.

In vulnerable LiteLLM versions, the authentication check on this endpoint is broken: the proxy accepts an arbitrary, attacker-supplied Bearer token and proceeds to establish a fully authenticated MCP session. The token is not validated against the proxy's master key, virtual key store, or SSO configuration. The attacker effectively self-issues their own credential.

The exploitation chain from a defender's perspective:

1. Reconnaissance: Attacker scans for exposed LiteLLM instances (default port 4000, distinctive HTTP fingerprints, /mcp endpoint discovery). Shodan/Censys exposure of LiteLLM proxies is common because teams deploy them behind weak or misconfigured ingress.
2. Session establishment: Attacker sends an MCP initialize request to the Streamable HTTP endpoint with any Bearer token value (e.g., Authorization: Bearer attacker-controlled-string). The server responds with a valid Mcp-Session-Id header.
3. Tool enumeration: Using the established session, the attacker calls tools/list to enumerate every MCP tool registered with the proxy — database query tools, file readers, internal API wrappers.
4. Exploitation of downstream trust: The attacker invokes tools/call against high-value tools. Because MCP tools frequently execute with the LiteLLM service's privileges, this can yield direct access to internal databases, filesystems, cloud metadata, or SaaS tenants.
5. Pivot potential: Exposed provider API keys, virtual keys, and stored credentials in the LiteLLM configuration become reachable, enabling lateral movement into model providers and billing accounts.

No user interaction, no valid credentials, and no prior foothold are required. The only prerequisite is network reachability to the MCP endpoint.

Exploitation status

• CISA KEV: Added 2026-09-02 — confirmed active exploitation in the wild
• Binding operational guidance: CISA's KEV entry references BOD 26-04 (Prioritizing Security Updates Based on Risk) and CISA's Forensics Triage Requirements, directing federal agencies — and by extension any organization using KEV as a prioritization signal — to apply vendor mitigations, follow applicable BOD 26-04 cloud service guidance, or discontinue use of the product if mitigations are unavailable
• Threat profile: Given the trivial exploitation barrier (a single HTTP request with a forged header) and the value of AI gateway compromise, expect scanning and exploitation to be opportunistic and widespread, not targeted

This KEV listing should drive the same response posture as any actively exploited internet-facing RCE-class issue: immediate inventory, immediate mitigation, and retroactive threat hunting.

Detection & Response

The following detections focus on the observable behaviors of this attack: unauthenticated MCP session establishment, anomalous MCP tool invocation, and LiteLLM processes initiating unexpected downstream activity. Tune thresholds to your baseline — MCP traffic should be relatively predictable in most environments.

Sigma Rules

The first rule targets web/proxy logs showing session establishment against the MCP endpoint, particularly requests that succeed without prior authentication activity. The second targets host-level behavior: the LiteLLM process spawning shells or unexpected child processes, which is a strong post-exploitation signal when MCP tools are abused for command execution.

---
title: LiteLLM MCP Endpoint Unauthenticated Session Establishment
id: 3f8a1c92-7e5d-4b21-a934-9c1e6f2d8a47
status: experimental
description: Detects HTTP requests to the LiteLLM MCP Streamable HTTP endpoint that establish sessions with arbitrary Bearer tokens, consistent with CVE-2026-59822 exploitation. Alerts on MCP initialize calls from sources with no prior authenticated request history or with anomalous token patterns.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-59822
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/03
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
  product: linux
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/mcp'
      - '/mcp/'
  selection_method:
    cs-method:
      - 'POST'
  selection_body:
    cs-body|contains:
      - '"initialize"'
      - 'tools/list'
      - 'tools/call'
  condition: selection_uri and selection_method and selection_body
falsepositives:
  - Legitimate MCP client connections from authorized internal tooling
  - AI developer workflows initializing sessions from approved workstations
level: high
---
title: LiteLLM Proxy Process Spawning Unexpected Child Processes
id: 8b2d5e41-3a9c-4f67-b218-6d4a8c1e5f93
status: experimental
description: Detects the LiteLLM proxy process (litellm, uvicorn, gunicorn serving LiteLLM) spawning shells, interpreters, or network utilities — a strong indicator of post-exploitation via abused MCP tools following CVE-2026-59822 session hijack.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-59822
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/03
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/litellm'
      - '/uvicorn'
      - '/gunicorn'
      - '/python'
      - '/python3'
  selection_parent_cmdline:
    ParentCommandLine|contains:
      - 'litellm'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
      - '/base64'
  condition: (selection_parent or selection_parent_cmdline) and selection_child
falsepositives:
  - MCP tools legitimately designed to execute shell commands (restrict tool access instead of suppressing detection)
  - Health-check scripts wrapping the LiteLLM service
level: high
---
title: MCP Tool Invocation From External Source Against LiteLLM
id: c47f9e23-1b6a-4d58-a392-7e3b5f8d2c61
status: experimental
description: Detects MCP tools/call or tools/list requests reaching the LiteLLM proxy from non-RFC1918 or otherwise unexpected source addresses, indicating potential external exploitation of CVE-2026-59822.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-59822
author: Security Arsenal
date: 2026/09/03
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: proxy
detection:
  selection:
    url|contains:
      - '/mcp'
    http_method: 'POST'
  filter_internal:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
      - '100.64.0.0/10'
  condition: selection and not filter_internal
falsepositives:
  - LiteLLM instances intentionally exposed to partners or remote developers via the internet (these should be re-architected, not whitelisted)
level: critical

KQL — Microsoft Sentinel / Defender

This hunt query assumes LiteLLM access logs are ingested into Sentinel via Syslog/CEF (e.g., from the host, container runtime, or an ingress controller in front of the proxy). It looks for MCP session establishment patterns and correlates with suspicious Bearer token behavior. The second query covers process execution telemetry for environments running LiteLLM on Windows or with Defender for Endpoint onboarded Linux hosts.

// Hunt 1: MCP session establishment and tool invocation against LiteLLM proxy
// Look for initialize/tools calls, especially where the same source IP uses many distinct tokens
let lookback = 14d;
CommonSecurityLog
| where TimeGenerated > ago(lookback)
| where RequestURL contains "/mcp" or RequestURL contains "/mcp/"
| where RequestMethod == "POST"
| extend TokenPresent = RequestHeaders has "Authorization"
| summarize Requests = count(),
            DistinctTokens = dcount(tostring(RequestHeaders)),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            URIs = make_set(RequestURL, 20)
  by SourceIP, DestinationHostName
| where Requests > 5 or DistinctTokens > 3
| order by Requests desc;

// Hunt 2: MCP endpoint access from external/unexpected sources via Syslog-ingested ingress logs
let lookback = 14d;
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has "/mcp" and SyslogMessage has "POST"
| where SyslogMessage has_any ("initialize", "tools/list", "tools/call")
| extend SourceIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| where SourceIP !startswith "10." and SourceIP !startswith "192.168." and SourceIP !startswith "172."
| summarize Hits = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by SourceIP, Computer
| order by Hits desc;

// Hunt 3: LiteLLM/uvicorn/gunicorn spawning suspicious child processes (Defender for Endpoint)
let lookback = 14d;
DeviceProcessEvents
| where TimeGenerated > ago(lookback)
| where InitiatingProcessCommandLine has "litellm"
   or InitiatingProcessFileName in~ ("uvicorn", "gunicorn", "litellm")
| where FileName in~ ("bash", "sh", "zsh", "curl", "wget", "nc", "ncat",
                      "python", "python3", "perl", "base64", "powershell.exe",
                      "cmd.exe", "pwsh.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName,
          InitiatingProcessCommandLine, FileName, ProcessCommandLine,
          AccountName, RemoteIP, RemoteUrl
| order by TimeGenerated desc;

Velociraptor VQL

Use this artifact across your Linux estate to identify running LiteLLM instances and their active network connections — both to build your exposure inventory and to spot established sessions from unexpected peers. Run it as a hunt; any host returning rows is a host you need to patch and investigate.

-- Inventory LiteLLM instances and enumerate their network connections
-- Identifies the LiteLLM/uvicorn proxy process, its listening port, and
-- any established remote sessions (potential attacker MCP sessions)
SELECT Pid,
       Name AS ProcessName,
       CommandLine,
       Exe,
       Username,
       CreateTime
FROM pslist()
WHERE CommandLine =~ 'litellm|uvicorn|mcp'
   OR Exe =~ 'litellm'

-- Enumerate network connections owned by LiteLLM proxy processes
-- Established connections on the MCP listener from external peers are
-- high-priority investigation leads
SELECT l.Pid,
       p.Name AS ProcessName,
       p.CommandLine,
       l.Family,
       l.Type,
       l.Laddr AS LocalAddress,
       l.Lport AS LocalPort,
       l.Raddr AS RemoteAddress,
       l.Rport AS RemotePort,
       l.Status
FROM netstat() AS l
JOIN pslist() AS p ON l.Pid = p.Pid
WHERE (p.CommandLine =~ 'litellm' OR p.Name =~ 'uvicorn|gunicorn|python')
  AND l.Status =~ 'ESTABLISHED|LISTEN'

If the second query returns ESTABLISHED connections to your MCP listener from addresses outside your expected client population (developer subnets, internal AI tooling), pull the LiteLLM access logs for that host immediately and review which MCP tools were invoked during the session window.

Remediation and Verification Script

The following Bash script inventories LiteLLM installations on a Linux host, reports the running version and exposed listeners, checks for signs of suspicious MCP session activity in logs, and upgrades the package. Adapt it for containerized deployments by rebuilding images with the patched base rather than upgrading in place.

#!/bin/bash
# CVE-2026-59822 LiteLLM Triage and Remediation Script
# Run as root on hosts suspected of running LiteLLM proxy

set -u

echo "=== [1] Identifying running LiteLLM processes ==="
ps aux | grep -Ei 'litellm|uvicorn|gunicorn' | grep -v grep || echo "No LiteLLM-like processes found"

echo ""
echo "=== [2] Checking installed LiteLLM version ==="
if command -v pip &>/dev/null; then
    pip show litellm 2>/dev/null | grep -E '^(Name|Version|Location)' || echo "litellm not found via pip"
fi
if command -v pip3 &>/dev/null; then
    pip3 show litellm 2>/dev/null | grep -E '^(Name|Version|Location)' || echo "litellm not found via pip3"
fi

echo ""
echo "=== [3] Checking for network-exposed listeners (default port 4000) ==="
ss -tlnp 2>/dev/null | grep -E ':4000|:8000|:8080' || echo "No common LiteLLM listeners detected"

echo ""
echo "=== [4] Checking whether MCP endpoint is reachable locally ==="
curl -s -o /dev/null -w "MCP endpoint HTTP status: %{http_code}\n" \
    -X POST http://127.0.0.1:4000/mcp \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer arbitrary-token-test" \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"triage","version":"0.1"}}}' \
    --max-time 5 2>/dev/null || echo "MCP endpoint not reachable on :4000 (check other ports)"

echo ""
echo "=== [5] Hunting logs for suspicious MCP session activity ==="
LOG_DIRS=("/var/log" "/var/log/containers" "$HOME/.litellm")
for dir in "${LOG_DIRS[@]}"; do
    if [ -d "$dir" ]; then
        echo "--- Searching $dir ---"
        grep -rEi 'mcp.*(initialize|tools/list|tools/call)' "$dir" 2>/dev/null | tail -n 25
    fi
done
journalctl -u litellm --since "14 days ago" 2>/dev/null | grep -Ei 'mcp|initialize|tools/' | tail -n 25 || true

echo ""
echo "=== [6] Upgrading LiteLLM to latest patched release ==="
echo "Review https://github.com/BerriAI/litellm/releases for the fixed version"
echo "covering CVE-2026-59822 before upgrading."
read -r -p "Proceed with pip upgrade of litellm now? [y/N] " confirm
if [[ "${confirm}" =~ ^[Yy]$ ]]; then
    pip3 install --upgrade litellm && echo "Upgrade complete. Restart the LiteLLM service."
else
    echo "Skipped upgrade. If you cannot patch immediately, apply the network workaround:"
    echo "  - Block external access to the MCP endpoint at your ingress/firewall"
    echo "  - iptables example: iptables -A INPUT -p tcp --dport 4000 ! -s 10.0.0.0/8 -j DROP"
fi

echo ""
echo "=== [7] Post-check: re-verify listener exposure and version ==="
ps aux | grep -Ei 'litellm' | grep -v grep || echo "LiteLLM not currently running"
ss -tlnp 2>/dev/null | grep -E ':4000' || echo "Port 4000 not listening"

For containerized deployments, do not exec-patch inside running containers. Pin the fixed image tag in your deployment manifest, rebuild, redeploy, and verify the MCP endpoint no longer accepts arbitrary tokens by re-running the curl probe in step 4 — a patched instance should reject the forged Bearer token with a 401 rather than returning a session ID.

Remediation

Given confirmed active exploitation and CISA KEV inclusion, sequence your response as follows:

1. Inventory immediately (hours, not days). Identify every LiteLLM instance in your environment: self-hosted proxies, Kubernetes deployments, developer workstations, CI pipelines, and shadow AI tooling. LiteLLM is frequently stood up by data science and platform teams outside formal change control — do not rely on your CMDB alone. Use the VQL hunt and network listener checks above.

2. Upgrade to the vendor-patched release. Apply the LiteLLM update that resolves the MCP Streamable HTTP authentication flaw per the vendor advisory and release notes at github.com/BerriAI/litellm. Verify the fix by sending an MCP initialize request with a forged Bearer token — a patched instance must return 401/403, not a session ID. If you are running a downstream distribution or a wrapped SaaS built on LiteLLM, confirm with your provider that their hosted version is patched.

3. If you cannot patch immediately, remove exposure. Per the CISA KEV required action, follow BOD 26-04 guidance — and if mitigations are unavailable, discontinue use of the product. Practical interim mitigations:

• Block network access to the MCP endpoint from any source other than explicitly authorized MCP clients (ingress rules, security groups, iptables).
• Place LiteLLM behind an authenticating reverse proxy (mTLS or SSO-aware) so the broken application-layer check is never reached unauthenticated.
• Disable the MCP gateway functionality entirely if your deployment does not require it.
• Restrict every registered MCP tool's scope and service-account privileges to minimum necessary — this bounds the blast radius of any session, legitimate or forged.

4. Hunt retroactively. Because exploitation was confirmed before many organizations patched, review at minimum the last 14–30 days of MCP endpoint traffic. Look for: session establishments from unfamiliar source IPs, a single source presenting multiple distinct Bearer tokens, tools/list followed by tools/call sequences from non-standard clients, and LiteLLM processes spawning unexpected child processes. CISA's KEV entry references its Forensics Triage Requirements — preserve access logs, container logs, and session artifacts before redeploying patched images, since redeployment typically destroys volatile evidence.

5. Rotate credentials. Treat any LiteLLM instance that was internet-reachable while vulnerable as compromised. Rotate provider API keys (OpenAI, Anthropic, Azure), LiteLLM master keys and virtual keys, MCP tool service-account credentials, and any secrets stored in LiteLLM configuration or its database.

6. Meet CISA deadlines. Federal civilian agencies are bound by the KEV remediation due date attached to this entry (per BOD 26-04). Private-sector organizations should adopt the same due date as their internal SLA — KEV-listed, trivially exploitable, internet-facing vulnerabilities are precisely the class of issue that appears in breach reports when patched "next sprint."

7. Re-architect for the long term. AI gateways like LiteLLM are becoming the new perimeter: they concentrate credentials, data access, and tool execution in one service. Treat them with the same rigor as your VPN concentrator or IdP — network-segment them, never expose them directly to the internet, ship their logs to your SIEM, and include them in your vulnerability management and pen-testing scope.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub