Intel

CVE-2026-59822

BerriAI LiteLLM — BerriAI LiteLLM Improper Authentication Vulnerability

criticalKEV: aktiv ausgenutztPoCEPSS 0.9 %

Beschreibung

LiteLLM ist ein Proxy-Server (AI Gateway), um LLM-APIs im OpenAI-Format (oder natives Format) aufzurufen. Vor Version 1.84.0 erlaubte der MCP Streamable HTTP-Endpunkt von LiteLLM einem unauthentifizierten Angreifer, einen gefälschten Authorization-Header zu verwenden, um einen OAuth2-Passthrough-Fallbackpfad auszulösen. Dieser Pfad ersetzte das fehlgeschlagene LiteLLM-Schlüsselprüfung durch ein leeres UserAPIKeyAuth()-Objekt und ermöglichte es Anfragen, die MCP-Tooling ohne gültigen LiteLLM-Schlüssel zu erreichen. Dieses Problem wurde in Version 1.84.0 behoben.

Quelle: BSIBSI_CSAFNVDCVELISTV5CISA_KEVCVEORGOSVOSV

Behebung & Mitigation

Warum sofort handeln?

Priorisierung

CVE-2026-59822 ist mit CVSS 8.2 (AV:N/AC:L/PR:N/UI:N) als kritisch für exponierte Instanzen einzustufen: Ein Angreifer benötigt keinerlei Vorwissen oder gültige Credentials, um eine vollständig authentifizierte MCP-Session zu etablieren und damit Zugriff auf alle angebundenen MCP-Tools zu erlangen — inklusive potenzieller Exfiltration von LLM-Prompts, Backend-API-Keys und Geschäftsdaten. Der EPSS-Wert (41,9. Perzentile) ist moderat, was auf noch begrenzte Massenausnutzung hindeutet, jedoch ist der Angriffsvektor trivial reproduzierbar. CISA-KEV-Aufnahme ohne bekannte Ransomware-Kampagne bedeutet, dass primär gezielte Angriffe auf KI-Infrastruktur (AI-Gateway-Missbrauch, Credential-Harvesting für LLM-Provider) im Vordergrund stehen. Für NIS2-pflichtige Organisationen, die LiteLLM als internes AI-Gateway betreiben, ist sofortiges Patchen oder Abschalten des MCP-Endpunkts Pflicht — insbesondere wenn Backend-API-Keys für kostenpflichtige LLM-Dienste im Spiel sind.

Runbook · Schritt 1

Sofort-Response (0-24 h)

  • Patch einspielen: LiteLLM auf Version 1.84.0 oder neuer aktualisieren. Dies ist der einzige vollständige Fix. Paketquelle: PyPI (pip install litellm==1.84.0) oder das jeweilige Container-Image des Herstellers — genaue Advisory-URL beim Hersteller nachschlagen.
  • MCP Streamable HTTP-Endpunkt deaktivieren, falls er nicht produktiv benötigt wird: Konfigurationsparameter für den MCP-Endpunkt in der LiteLLM-Konfigurationsdatei (config.yaml) auf disabled setzen oder den entsprechenden Route-Handler über Reverse-Proxy-Regeln blockieren, bis der Patch eingespielt ist.
  • Netzwerkzugang einschränken: Den MCP-Endpunkt (typischerweise /mcp oder /mcp/...) sofort über Firewall-/Reverse-Proxy-ACLs auf vertrauenswürdige interne IP-Bereiche beschränken — kein öffentlicher Internetzugang.
  • Laufende Sessions prüfen: Alle aktiven MCP-Sessions und API-Schlüssel in LiteLLM invalidieren (litellm admin-Konsole oder Datenbank-Direktzugriff). Insbesondere Sessions ohne gültigen LiteLLM-Schlüssel identifizieren und beenden.
  • Zugriffslogs sichten: Zugriffslogs des LiteLLM-Proxys und des vorgelagerten Reverse-Proxys auf Anfragen an /mcp-Pfade mit beliebigen Authorization: Bearer-Headern rückwirkend für mindestens 30 Tage prüfen.

Runbook · Schritt 2

Mitigation-Layer

  • Reverse-Proxy-Filterung (WAF/Nginx/HAProxy): Anfragen an den MCP-Endpunkt (/mcp, /mcp/*) blockieren, die keinen bekannten, vorab definierten Bearer-Token-Wert tragen. Beispiel-Nginx-Snippet: location /mcp { if ($http_authorization !~* "^Bearer <VALID_TOKEN_PATTERN>$") { return 403; } } — als Übergangslösung bis zum Patch.
  • Netzwerksegmentierung: LiteLLM-Instanzen in ein dediziertes internes Netz-Segment (VLAN/Security-Zone) verschieben; ausgehende Verbindungen zu LLM-Backend-APIs (OpenAI, Azure OpenAI, etc.) nur über explizite Firewall-Regeln erlauben. Kein direkter Internetzugang für den MCP-Port.
  • IAM/Least-Privilege: Sicherstellen, dass der LiteLLM-Prozess nur mit minimalen Berechtigungen läuft (kein Root, kein Zugriff auf Secrets außerhalb des eigenen Namespaces). Kubernetes-Deployments: securityContext.runAsNonRoot: true, readOnlyRootFilesystem: true.
  • OAuth2-Passthrough deaktivieren: Sofern die LiteLLM-Konfiguration einen OAuth2-Passthrough-Fallback erlaubt, diesen explizit deaktivieren (oauth2_passthrough: false in config.yaml), um den Angriffsvektor auf Konfigurationsebene zu schließen.
  • API-Gateway vorschalten: Einen dedizierten API-Gateway (z. B. Kong, AWS API Gateway) mit Authentifizierungspflicht vor LiteLLM schalten, sodass unauthentifizierte Anfragen den LiteLLM-Prozess gar nicht erreichen.

Runbook · Schritt 3

Detection-Regeln

  • Web-Server-Accesslog-Muster: Anfragen auf /mcp oder /mcp/ mit HTTP-Status 200 oder 101 und einem Authorization-Header, der keinem bekannten internen Token-Muster entspricht. SPL-Snippet: index=proxy_logs uri_path="/mcp*" status IN (200,101) | where NOT match(authorization, "^Bearer <KNOWN_PATTERN>")
  • LiteLLM-Applikationslog: Log-Einträge, die UserAPIKeyAuth() mit leerem oder null-wertigem API-Key-Feld enthalten, deuten auf erfolgreiche Ausnutzung des Fallback-Pfads hin. Suche nach: "UserAPIKeyAuth" AND ("api_key=None" OR "api_key=''")
  • Anomalie im LLM-Backend-Traffic: Unerwartete Anstiege in ausgehenden API-Aufrufen zu LLM-Providern (OpenAI, Azure, etc.) ohne korrespondierende interne Nutzer-Session — Zeek/Suricata: ausgehende HTTPS-Verbindungen zu api.openai.com oder *.openai.azure.com aus dem LiteLLM-Segment, die keiner authentifizierten internen Session zugeordnet werden können.
  • Sigma-Regelform: 
    title: LiteLLM MCP Unauthenticated Session (CVE-2026-59822)
logsource: { category: webserver }
detection:
  selection:
    cs-uri-stem|startswith: '/mcp'
    sc-status: [200, 101]
  filter:
    cs-Authorization|startswith: 'Bearer <KNOWN_VALID_PREFIX>'
  condition: selection and not filter
  • EDR/Container-Prozessbaum: Unerwartete Kindprozesse des LiteLLM-Prozesses (z. B. Shell-Spawns, curl, wget) als Hinweis auf Post-Exploitation über MCP-Tooling. Sysmon EID 1 / auditd execve-Syscall mit Parent-PID des LiteLLM-Prozesses.

Metriken

Severity
critical
Priority-Score
202.81
KEV-Status
Aktiv ausgenutzt
Exploit-Reife
aktiv ausgenutzt (KEV)
XIEM Effective CVSS
8.8
Quelle: nvd-v4
CVSS v3
8.2
CVSS v4
8.8
EPSS-Perzentil
56.7 %
Hoch — CVE rangiert über dem Median aller heute bewerteten CVEs (Rang ≥ 36 %).
EPSS-Score
0.9 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-07-08 20:16 UTC
CWE
CWE-287, CWE-306

Weakness-Klassen (CWE)

  • CWE-287Class

    Improper Authentication

    When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

    cwe.mitre.org →

  • CWE-306Base

    Missing Authentication for Critical Function

    The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

    cwe.mitre.org →

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. CVE Modified2026-09-03 13:05 UTC· 134c704f-9b21-4f2e-91b3-4a467353bcc0
    • SSVC: {"id":"CVE-2026-59822","role":"CISA Coordinator","options":[{"exploitation":"active"},{"automatable":"yes"},{"technic… → {"id":"CVE-2026-59822","role":"CISA Coordinator","options":[{"exploitation":"active"},{"automatable":"yes"},{"technic…
  2. CVE CISA KEV Update2026-09-02 19:00 UTC· 9119a7d8-5eab-497f-8521-727c672e3725
    • Date Added: 2026-09-02
    • Due Date: 2026-09-02
    • Required Action: 2026-09-02
    • Vulnerability Name: 2026-09-02
  3. CVE Modified2026-09-02 18:20 UTC· 134c704f-9b21-4f2e-91b3-4a467353bcc0
    • Reference: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-59822
    • SSVC: {"id":"CVE-2026-59822","role":"CISA Coordinator","options":[{"exploitation":"none"},{"automatable":"yes"},{"technical… → {"id":"CVE-2026-59822","role":"CISA Coordinator","options":[{"exploitation":"active"},{"automatable":"yes"},{"technic…

Betroffene Produkte

Aus der Hersteller-/CERT-Meldung extrahierte Produkte und Versionsbereiche. Ein Version-Range wie „<4.14.6“ impliziert die Update-Empfehlung „auf 4.14.6 oder höher aktualisieren“.

  • litellm

    litellm1.84.0

Öffentliche Exploit-Referenzen

Öffentliche Proof-of-Concepts und Detection-Templates für diese Schwachstelle. Die Reife reicht von gemeldeten PoCs über funktionsfähige Detection-Skripte bis hin zu vollständig waffenfähigen Exploit-Modulen. NEOSEC mirrort den Code intern für forensische Analysen; nach außen verlinken wir ausschließlich auf die Original-Quellen.

Quellen & Referenzen

IDCVE-2026-59822