CVE-2026-59822 in BerriAI LiteLLM wird aktiv ausgenutzt

Kurzfassung

CVE-2026-59822 betrifft BerriAI LiteLLM. Die Schwachstelle sitzt im MCP Streamable HTTP Endpoint und erlaubt laut Beschreibung einem nicht authentifizierten Angreifer, mit einem beliebigen Bearer Token eine authentifizierte MCP-Sitzung aufzubauen. CISA führt den Fehler im KEV-Katalog; damit gilt er als aktiv ausgenutzt.

Für Unternehmen im DACH-Raum ist das kein theoretisches Thema. Wer LiteLLM produktiv betreibt, sollte den Dienst jetzt priorisiert prüfen, vor allem wenn der Endpoint aus dem Netz erreichbar ist.

Was ist passiert?

Bei LiteLLM liegt ein Fehler in der Authentifizierung vor. Statt eine gültige Identität sauber zu erzwingen, akzeptiert der betroffene MCP Streamable HTTP Endpoint unter Umständen einen frei gewählten Bearer Token. Das reicht in dem Szenario offenbar aus, um eine Sitzung als authentifizierter Nutzer zu eröffnen.

Die Folge ist klar: Ein externer Angreifer kann die vorgelagerte Schutzschicht umgehen. Welche Aktionen danach im konkreten Setup möglich sind, hängt von der angebundenen MCP-Umgebung und den Rechten der Sitzung ab. Genau deshalb ist die Internet-Exposition hier der erste Prüfpunkt.

Technische Details

Die Schwachstelle ist als Improper Authentication beschrieben. Betroffen ist der MCP Streamable HTTP Endpoint von BerriAI LiteLLM. Der Angriff braucht nach derzeitigem Stand keine vorherige Anmeldung. Das macht den Fehler für öffentlich erreichbare Instanzen besonders brisant.

CISA ordnet CVE-2026-59822 als in freier Wildbahn ausgenutzt ein. Das ist mehr als ein Warnhinweis. Sobald eine Schwachstelle im KEV-Katalog landet, sollte sie in der eigenen Patch- und Risikopriorisierung ganz oben stehen.

Zur Schwere nennt die Quelle keine CVSS-Zahl. Auch zur Frage, welche Versionen genau betroffen sind oder ob bereits ein Fix vorliegt, bleibt der Auszug offen. Wer eine konkrete Betroffenheit klären will, muss die Herstellerinformationen und die eigene Installationslage gegenprüfen.

Wer ist betroffen?

Direkt betroffen sind Betreiber von BerriAI LiteLLM. Privatnutzer spielen hier kaum eine Rolle, denn es geht um eine Entwicklungs- und Integrationskomponente, die typischerweise in Server- und Plattformumgebungen läuft.

Im DACH-Raum sollten vor allem Plattformteams, KI-Teams und Betreiber von internen API- oder Agenten-Stacks hinschauen. Kritisch wird es dort, wo LiteLLM aus dem Internet erreichbar ist oder über Segmentgrenzen hinweg genutzt wird. Auch Cloud-Instanzen fallen darunter, wenn sie nicht sauber abgeschottet sind.

Empfohlene Maßnahmen

Prüfen Sie zuerst, ob LiteLLM überhaupt im Bestand ist. Dann klären Sie, ob der MCP Streamable HTTP Endpoint extern erreichbar ist. Wenn ja, behandeln Sie die Instanz als vorrangiges Risiko.

Setzen Sie laut CISA die Maßnahmen nach Herstelleranweisung um und beachten Sie die Vorgaben aus BOD 26-04 sowie die Anforderungen für die forensische Erstprüfung. Wenn für Ihre Version keine wirksame Minderung verfügbar ist, sollte der Dienst bis auf Weiteres abgeschaltet werden. Das klingt hart, ist hier aber die saubere Antwort.

Wer eine Cloud-Umgebung betreibt, muss zusätzlich die Exposition jedes betroffenen Assets bewerten und die Patch-Priorisierung nach Risiko ausrichten. Ein Firewall-Regelwerk allein reicht nicht, wenn der Dienst logisch weiterhin offen bleibt.

Herstellerhinweise finden Leser über die offizielle Quelle: NVD-Eintrag zu CVE-2026-59822.

Einschätzung von CyberSecurity-News.de

Die Lage ist ernst, aber nicht dramatischer, als sie ist. Entscheidend ist nicht der Name der Schwachstelle, sondern die Kombination aus fehlender Authentifizierung und aktiver Ausnutzung. Das ist der Punkt, an dem aus einem normalen Patchfall ein Betriebsrisiko wird.

Die Informationslage bleibt dünn. CISA stuft den Fehler als ausgenutzt ein, doch der Auszug nennt keine Versionen, keine CVSS-Bewertung und keinen eindeutigen Fixstand. Das erschwert die Priorisierung nicht grundlegend, macht sie aber etwas mühsamer. Admins müssen jetzt selbst sauber inventarisieren statt auf eine bequeme Kurzmeldung zu warten.

Wer LiteLLM nur intern und stark abgeschottet betreibt, dürfte weniger akut betroffen sein. Öffentlich erreichbare Instanzen oder Umgebungen mit vielen Integrationen sollten dagegen heute noch geprüft werden.

Fazit

CVE-2026-59822 ist ein Authentifizierungsfehler mit echtem Betriebsrisiko. Die aktive Ausnutzung durch Angreifer macht die Sache dringlich. Für Betreiber von BerriAI LiteLLM gilt: Bestand prüfen, Erreichbarkeit einschränken, Herstellermaßnahmen umsetzen und bei fehlender Minderung den Dienst stoppen.