Wer im eigenen Homelab oder auf einem Server ein Sprachmodell selbst betreibt, statt es bei einem großen Anbieter zu mieten, kommt an Serving-Frameworks wie LightLLM kaum vorbei — es verteilt die Inferenz-Last auf mehrere Knoten und macht so aus mehreren Servern eine gemeinsame KI-Infrastruktur. Genau in diesem Verteil-Mechanismus steckt jetzt eine Lücke, die alles andere als harmlos ist.
DIE LÜCKE: CVE-2026-93839, CVSS 9,8
Betroffen ist der PD Master (Prefill/Decode Master), also die Komponente, die in LightLLM entscheidet, welcher Rechenknoten welchen Teil einer Anfrage übernimmt. Ihr WebSocket-Endpunkt /pd_register nimmt Registrierungsanfragen neuer Knoten entgegen — und prüft dabei laut Sicherheitsforschern nicht, ob die anfragende Gegenstelle überhaupt echt und autorisiert ist. Ein Angreifer muss lediglich ein passend geformtes JSON-Paket an den Endpunkt schicken, um sich selbst als vertrauenswürdigen Knoten einzuschleusen — komplett ohne Zugangsdaten.
WAS EIN ANGREIFER DAMIT ANSTELLEN KANN
Die Folgen sind für ein KI-System besonders unangenehm: Ist ein bösartiger Knoten erst registriert, kann er komplette Nutzer-Prompts mitlesen, die eigentlich an seinen Socket weitergeleitet werden sollten — also genau die Eingaben, die Nutzer an das eigene Sprachmodell schicken. Zusätzlich kann der Angreifer einen echten, legitimen Knoten durch seinen eigenen ersetzen und damit den Dienst lahmlegen, oder den PD Master dazu bringen, Anfragen an interne Netzwerkadressen zu schicken, die von außen eigentlich gar nicht erreichbar sein sollten.
KEINE HÜRDE FÜR DEN ANGRIFF
Die CVSS-Bewertung von 9,8 kommt nicht von ungefähr: Der Angriff läuft über das Netzwerk, braucht keinerlei Vorkenntnisse über Zugangsdaten, keine Interaktion eines Nutzers und keine komplizierte Angriffskette. Es reicht, dass der /pd_register-Endpunkt von außen erreichbar ist. Betroffen sind laut Advisory alle Versionen von LightLLM bis einschließlich 1.2.0. Die technische Einordnung erfolgt unter der Schwachstellenklasse CWE-306 — „fehlende Authentifizierung für eine kritische Funktion” — ein Klassiker, der in verteilten Systemen immer wieder auftaucht, sobald interne Kommunikationswege versehentlich offen ins Netz zeigen.
WAS BETREIBER JETZT TUN SOLLTEN
Eine offiziell benannte, bereits gepatchte Version war zum Zeitpunkt der Veröffentlichung noch nicht klar kommuniziert — wer LightLLM produktiv einsetzt, sollte deshalb zuerst prüfen, ob der PD-Master-Port überhaupt aus dem öffentlichen Internet erreichbar ist. Im Zweifel gehört die Schnittstelle sofort hinter eine Firewall oder ein VPN, sodass nur die eigenen, bekannten Inferenz-Knoten sie erreichen können. Wer LightLLM in einem Cluster über mehrere physische Standorte betreibt, sollte zusätzlich prüfen, ob eine Segmentierung per VLAN oder WireGuard-Tunnel zwischen den Knoten technisch machbar ist, statt sich allein auf die Anwendungsebene zu verlassen.
EIN MUSTER, DAS SICH WIEDERHOLT
Die Lücke reiht sich in eine Serie ähnlicher Vorfälle bei relativ jungen KI-Infrastruktur-Projekten ein: Tools, die ursprünglich für den schnellen Forschungseinsatz in vertrauenswürdigen Umgebungen entwickelt wurden, landen zunehmend in produktiven, teils öffentlich erreichbaren Setups — oft schneller, als die Sicherheitsarchitektur mitwächst. Für alle, die gerade mit eigenem Self-Hosting von Sprachmodellen liebäugeln, ist das eine Erinnerung: Auch KI-Werkzeuge brauchen dieselbe Netzwerk-Hygiene wie jede andere Serverkomponente auch.