Kurzfassung

LightLLM bis einschließlich Version 1.2.0 ist von der Schwachstelle CVE-2026-90919 betroffen. Die Lücke erlaubt Remote-Code-Ausführung über das Netzwerk ohne Anmeldung oder Nutzerinteraktion; der technische Schweregrad liegt bei CVSS 9.3 und ist damit kritisch. Gefährlich wird das vor allem dann, wenn der betroffene Config Server aus anderen Netzen erreichbar ist.

Was ist passiert?

Bei LightLLM steckt die Schwachstelle im Config Server. Dort akzeptiert ein nicht authentifizierter WebSocket-Endpunkt mit dem Namen /visual_register eingehende Verbindungen und verarbeitet den ersten Client-Frame unsicher.

Ein Angreifer kann an dieser Stelle präparierte serialisierte Daten einschleusen. Dadurch lässt sich auf dem betroffenen System eigener Code mit den Rechten des Config-Server-Prozesses ausführen. Für Unternehmen ist das vor allem in Entwicklungs-, KI- und Inferenz-Umgebungen relevant, in denen LightLLM intern oder testweise oft schnell bereitgestellt wird und Sicherheitsgrenzen nicht immer sauber gezogen sind.

Technische Details

Ursache ist laut NVD die direkte Übergabe des ersten Frames an pickle.loads(). In Python gilt pickle bei untrusted Input seit Jahren als hochriskant, weil sich beim Deserialisieren Codepfade auslösen lassen, etwa über eine manipulierte __reduce__-Methode.

Der CVSS-Basiswert liegt bei 9.3 nach CVSS 4.0. Der Vektor zeigt: Angriffe sind über das Netzwerk möglich, die Angriffskomplexität ist gering, es sind keine Berechtigungen nötig und keine Nutzerinteraktion ist erforderlich. Dieser Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch, ob sie bereits aktiv ausgenutzt wird.

Gelingt der Angriff, läuft der eingeschleuste Code mit den Rechten des Config Servers. Wie weit ein Angreifer danach im System kommt, hängt stark davon ab, unter welchem Benutzerkonto der Dienst läuft, welche Netzwerkpfade offen sind und ob weitere Schutzmechanismen wie Container-Isolation, restriktive Dateirechte oder Segmentierung greifen.

Wer ist betroffen?

Betroffen ist LightLLM bis einschließlich Version 1.2.0. Nicht genannt sind derzeit weitergehende Angaben dazu, ob nur bestimmte Bereitstellungsarten, Standardkonfigurationen oder optionale Komponenten verwundbar sind.

Praktisch relevant ist die Lücke vor allem für Organisationen, die LightLLM mit aktivem Config Server betreiben und dessen Port aus internen Netzen, aus Shared-Hosting-Umgebungen oder schlimmstenfalls aus dem Internet erreichbar gemacht haben. Für die meisten Leser ohne Bezug zu KI-Inferenzservern ist das Thema dagegen kaum relevant.

Empfohlene Maßnahmen

Prüfen Sie zuerst, ob in Ihrer Umgebung LightLLM bis 1.2.0 eingesetzt wird und ob der Config Server aktiv ist. Priorität hat die Erreichbarkeit des betroffenen Ports: Sperren Sie den Zugriff sofort per Firewall, Security Group, Reverse Proxy oder Netzsegmentierung, wenn der Dienst nicht zwingend von anderen Systemen erreichbar sein muss.

Falls der Config Server benötigt wird, beschränken Sie den Zugriff auf klar definierte Quelladressen. Stellen Sie Dienste dieser Art nicht direkt ins Internet. Betreiben Sie den Prozess mit minimalen Rechten und vermeiden Sie privilegierte Container, weitreichende Host-Mounts und gemeinsam genutzte Service-Konten.

Kontrollieren Sie Protokolle und Telemetrie auf ungewöhnliche WebSocket-Verbindungen zum Endpunkt /visual_register. Suchen Sie nach verdächtigen Prozessstarts, Shell-Aufrufen, unerwarteten Dateien und ausgehenden Netzwerkverbindungen im zeitlichen Zusammenhang mit Zugriffen auf den Config Server.

Ob ein Patch oder eine feste korrigierte Version bereitsteht, ist hier nicht mitgeteilt. Bis belastbare Herstellerinformationen vorliegen, sind Abschottung und Deaktivierung der betroffenen Funktion die wichtigsten Sofortmaßnahmen.

Einschätzung von CyberSecurity-News.de

Technisch ist die Schwachstelle ernst: unauthentifizierte Remote-Code-Ausführung auf einem netzwerkfähigen Dienst gehört in jede Priorität-1-Liste. Besonders problematisch ist, dass hier unsichere Deserialisierung mit pickle an einem offen erreichbaren Endpunkt zusammenkommt – ein vermeidbarer Konstruktionsfehler.

Die Informationslage bleibt aber unvollständig. NVD liefert die Kerndaten, doch belastbare Angaben zu behobenen Versionen, Standardports, Standardaktivierung des Config Servers oder konkreten Mitigations des Projekts fehlen hier. Für Administratoren heißt das: nicht auf einen späteren Patch-Hinweis warten, sondern Erreichbarkeit sofort prüfen und den Dienst bis zur Klärung defensiv absichern.

Fazit

Wenn Sie LightLLM betreiben, behandeln Sie CVE-2026-90919 wie einen akuten Infrastrukturfehler. Prüfen Sie noch heute die eingesetzten Versionen, isolieren Sie den Config Server vom Netz und überwachen Sie betroffene Systeme auf Anzeichen einer Kompromittierung. Ohne LightLLM-Einsatz besteht für die meisten Organisationen kein unmittelbarer Handlungsdruck.

Quellenangabe

Weiterführende technische Informationen finden Sie beim NVD-Eintrag zu CVE-2026-90919.