Port 5555 klingt nicht nach einem Ort, an dem viel auf dem Spiel steht. Kein Nutzer sieht ihn, kein Chatfenster verrät, dass es ihn gibt. Auf manchen KI-Servern wartet dort lediglich ein technischer Dienst auf Nachrichten anderer Prozesse. Doch eine einzige präparierte Nachricht kann genügen, um über diesen unscheinbaren Zugang in das System einzudringen.
Die Schwachstelle trägt die Kennung CVE-2026-105192 und betrifft LMCache, eine Open-Source-Komponente zur Beschleunigung großer Sprachmodelle. JFrog Security Research veröffentlichte die Analyse am 7. Oktober 2026 und bewertete die Lücke mit 9,8 von 10 Punkten. Unter bestimmten Bedingungen kann ein Angreifer ohne Anmeldung eigenen Code auf dem betroffenen Rechner ausführen. Damit gilt die Schwachstelle als kritisch. Recherchequelle: JFrog Security Research
Brisant ist nicht nur der Fehler selbst. Die Schwachstelle rückt einen Aspekt in den Vordergrund, der bei öffentlichen Diskussionen über künstliche Intelligenz häufig vernachlässigt wird: die technische Infrastruktur, auf der die KI-Modelle aufbauen. Während öffentlich über Trainingsdaten, Modellfähigkeiten und Sicherheitsregeln gestritten wird, wächst im Hintergrund ein technischer Unterbau aus Serverdiensten, Speicherverfahren und Kommunikationswegen. Er soll Antworten beschleunigen und Kosten senken, vergrößert zugleich aber die Angriffsfläche.
Das Gedächtnis vor der Antwort
Ein Sprachmodell erzeugt eine Antwort nicht so unmittelbar, wie es auf dem Bildschirm wirkt. Bevor das erste Wort erscheint, verarbeitet das System den bisherigen Text und berechnet für jedes Textelement interne Zustände. Bei langen Gesprächen, umfangreichen Dokumenten oder häufig wiederkehrenden Anweisungen kostet diese unsichtbare Vorbereitung Zeit und Rechenleistung.
Ein sogenannter KV-Cache bewahrt Teile der Berechnungen auf. Taucht derselbe Textanfang später erneut auf, muss das Modell nicht wieder bei null beginnen, sondern kann auf vorhandene Zwischenergebnisse zurückgreifen. Das ähnelt weniger einem menschlichen Gedächtnis als einem sorgfältig sortierten Stapel bereits ausgefüllter Rechenblätter: Was schon bearbeitet wurde, muss nicht noch einmal berechnet werden.
LMCache führt dieses Prinzip weiter. Die Software kann solche Cache-Daten außerhalb des eigentlichen Modellprozesses aufbewahren, etwa im Arbeitsspeicher, auf lokalen Datenträgern oder in entfernten Speichersystemen. Dadurch können mehrere Modellserver dieselben gespeicherten Berechnungen wiederverwenden. Vor allem bei langen Kontexten verkürzt das die Zeit bis zum ersten ausgegebenen Wort und spart GPU-Rechenzeit.
Recherchequelle: LMCache-Dokumentation
Für Betreiber großer KI-Dienste ist das attraktiv. Eine einzelne Antwort mag nur Sekunden dauern, doch bei Tausenden parallelen Anfragen summiert sich jede wiederholte Berechnung. Damit gewinnt der Cache über seine rein technische Funktion hinaus zunehmend an wirtschaftlicher Bedeutung und wird zu einem wichtigen Bestandteil der KI-Infrastruktur.
Bei skalierbaren Installationen empfiehlt LMCache seinen Multiprocess-Modus. Dabei läuft der Cache als eigenständiger Dienst, an den sich ein oder mehrere Inferenzprozesse anschließen. Auf diese Weise lassen sich gespeicherte Berechnungen zwischen mehreren Modellinstanzen teilen. Die Trennung schafft allerdings auch eine neue Netzwerkgrenze – und genau dort beginnt das Sicherheitsproblem.
Eine Nachricht wird zum Befehl
Im betroffenen Betriebsmodus kommunizieren die Prozesse über ZeroMQ, kurz ZMQ. Der LMCache-Server lauscht dabei auf Port 5555; als voreingestellte Adresse nennt die aktuelle Dokumentation localhost. Betreiber können den Dienst jedoch an andere Adressen binden, etwa wenn mehrere Rechner innerhalb eines Clusters darauf zugreifen sollen. Recherchequelle: LMCache-Konfigurationsreferenz
DQo8ZGl2IGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWQiIGRhdGEtZXh0aG9yaWEtYWQtc2xvdD0iMDEiIGRhdGEtZXh0aG9yaWEtYWQtcHJvdmlkZXI9ImFtYXpvbiI+PGRpdiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19tZXRhIj48c3BhbiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19iYWRnZSI+V2VyYnVuZzwvc3Bhbj48c3BhbiBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19wcm92aWRlciI+QW1hem9uPC9zcGFuPjwvZGl2PjxzdHJvbmcgY2xhc3M9ImV4dGhvcmlhLWFtYXpvbi1hZF9fdGl0bGUiPkJhY2sgaW4gQmxhY2sgW1ZpbnlsIExQXTwvc3Ryb25nPjxhIGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWRfX2N0YSIgaHJlZj0iaHR0cHM6Ly9saW5rLmFtYXpvbi9CMDg1SlpLNWsiIHRhcmdldD0iX2JsYW5rIiByZWw9InNwb25zb3JlZCBub2ZvbGxvdyBub29wZW5lciBub3JlZmVycmVyIiBkYXRhLWV4dGhvcmlhLWxpbmstbWFuYWdlcj0iMSIgZGF0YS1leHRob3JpYS1saW5rLXR5cGU9ImV4dGVybmFsIiBkYXRhLWV4dGhvcmlhLWFkLWxpbms9ImFtYXpvbiI+QmVpIEFtYXpvbiBhbnNlaGVuIDxzcGFuPihiZXphaGx0ZXIgTGluayk8L3NwYW4+PC9hPjxzbWFsbCBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX19kaXNjbG9zdXJlIj7DnGJlciB1bnNlcmUgQW1hem9uLVBhcnRuZXJsaW5rcyBlcmhhbHRlbiB3aXIgYmVpIHF1YWxpZml6aWVydGVuIFZlcmvDpHVmZW4gZWluZSBQcm92aXNpb24uPC9zbWFsbD48L2Rpdj4NCg==Nach der Analyse von JFrog fehlt dem ZMQ-Dienst eine Authentifizierung. Weder ein Passwort noch eine andere Prüfung stellt zuverlässig sicher, dass eine Nachricht tatsächlich von einem berechtigten LMCache-Prozess stammt. Solange der Port über das Netzwerk zugänglich ist, können sämtliche Rechner innerhalb dieses Netzes Daten an den betreffenden Dienst übermitteln.
Schon die fehlende Authentifizierung birgt ein Risiko. Besonders problematisch ist die fehlende Authentifizierung in Verbindung mit dem Verfahren, das LMCache zur Verarbeitung bestimmter Daten einsetzt. Für einen Teil der übertragenen Objekte verwendet die Software das Python-Modul pickle. Es wandelt komplexe Python-Objekte in übertragbare Daten um und rekonstruiert sie später daraus.
Das ist bequem, eignet sich aber nicht für Daten aus nicht vertrauenswürdigen Quellen. Die Python-Dokumentation warnt ausdrücklich davor, fremde oder veränderte Daten mit pickle zu deserialisieren. Ein entsprechend gestaltetes Objekt kann beim Einlesen Programmcode ausführen.
Recherchequelle: Python-Dokumentation
Genau an dieser Stelle greifen die beiden Schwächen ineinander: Der Dienst ist ohne Anmeldung erreichbar und verarbeitet eingehende Inhalte mit pickle.loads. Laut JFrog geschieht die Deserialisierung bereits beim Dekodieren der Argumente, also noch bevor die eigentliche Bearbeitung der Anfrage beginnt. Eine manipulierte Nachricht kann so Code mit den Rechten des LMCache-Prozesses zur Ausführung bringen.
Dokumentiert ist dieses Verhalten auch in den technischen Unterlagen des Projekts. Das LMCache-Design beschreibt, dass die Methoden zur Serialisierung und Deserialisierung auf pickle.dumps und pickle.loads beruhen. Beim Transport soll so die Information erhalten bleiben, zu welcher konkreten Objektklasse die Daten gehören. Was zunächst wie eine praktische Abkürzung wirkt, wird an einer Netzwerkgrenze zum Sicherheitsrisiko.
Recherchequelle: LMCache-Entwurfsdokumentation
Kritisch, aber nicht überall erreichbar
Die Bewertung von 9,8 Punkten verlangt nach Einordnung. Nicht jede Installation von LMCache ist automatisch aus der Ferne angreifbar.
In der Standardkonfiguration ist der betroffene Port an localhost gebunden. Eine Verbindung können dann nur Prozesse auf demselben Rechner herstellen. Auch eine Installation, bei der LMCache ausschließlich innerhalb des vLLM-Prozesses läuft, öffnet den beschriebenen Multiprocess-Port nicht. Ein unmittelbares Fernangriffsrisiko entsteht vor allem dann, wenn ein Betreiber den ZMQ-Dienst an eine über das Netzwerk erreichbare Adresse bindet – beispielsweise für einen verteilten Betrieb über mehrere Server.
Auf eine solche Netzwerkkonfiguration bezieht sich die hohe CVSS-Bewertung ausdrücklich. Sie bedeutet nicht, dass jeder öffentlich zugängliche Chatbot über LMCache übernommen werden könnte. Sie verdeutlicht vielmehr das Ausmaß der möglichen Schäden, wenn es einem Angreifer gelingt, auf den anfälligen Dienst zuzugreifen. Auch die GitHub Advisory Database bewertet die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit jeweils mit dem Höchstwert. Recherchequelle: GitHub Advisory Database
Entscheidend sind außerdem die Rechte des LMCache-Prozesses, denn der eingeschleuste Code läuft mit denselben Berechtigungen wie LMCache. In JFrogs Test lief der Prozess in den offiziellen Container-Images als Root. In einer solchen Umgebung erhält der Angreifer nicht nur Zugang zu einem begrenzten Dienst, sondern weitreichende Kontrolle innerhalb des Containers. Ob daraus auch ein Zugriff auf den zugrunde liegenden Host wird, hängt von dessen Konfiguration und den eingeräumten Containerrechten ab.
Noch kein reguläres Sicherheitsupdate
JFrog nennt alle LMCache-Versionen ab 0.3.9 als betroffen. Zum Zeitpunkt der Veröffentlichung war weder für die reguläre Version 0.5.5 noch für die untersuchten Vorabversionen der Reihe 0.5.6 eine Korrektur verfügbar.
Mit Stand vom 9. Oktober führt PyPI 0.5.5 vom 12. September 2026 weiterhin als neueste reguläre Veröffentlichung. Auch die öffentlich einsehbare Entwicklungsfassung enthält nach wie vor die auf pickle beruhende Deserialisierung. Ein stabiles, allgemein verfügbares Update, auf das Betreiber einfach wechseln könnten, gibt es damit derzeit nicht. Recherchequelle: PyPI
Bis eine korrigierte Fassung erscheint, rät JFrog dazu, den ZMQ-Dienst nicht an eine frei erreichbare Adresse zu binden. Der Port sollte auf localhost oder ein streng kontrolliertes Clusternetz beschränkt und zusätzlich durch Firewallregeln geschützt werden. Eine solche Abschottung reduziert die Zahl möglicher Angreifer, ersetzt jedoch keine echte Authentifizierung: Jeder Rechner, der den Dienst innerhalb des erlaubten Netzes erreicht, kann weiterhin Nachrichten senden.
Eine dauerhafte Reparatur muss tiefer ansetzen. Netzwerkdaten dürfen nicht ungeprüft an pickle.loads gelangen. Zusätzlich muss die Kommunikation verlässlich authentifiziert werden, beispielsweise über kryptografisch abgesicherte Nachrichten oder einen entsprechend geschützten Transport.
Die Bedeutung der LMCache-Lücke reicht damit über einen offenen Port hinaus. Moderne KI-Systeme bestehen längst nicht mehr nur aus einem Modell und einigen Grafikkarten. Rund um die Modelle wächst ein Geflecht aus Caches, Speicherdiensten, Schnittstellen und verteilten Prozessen, das für die nötige Geschwindigkeit sorgt. Solche technischen Abkürzungen sparen Rechenzeit, können zugleich aber neue, leicht übersehene Angriffswege schaffen.
Weiterführende Informationen
Quellenhinweis: Einzelne Fakten, Einschätzungen und Prognosen dieses Beitrags stützen sich auf Veröffentlichungen der nachfolgend genannten Unternehmen und Institutionen. Die Links dienen zugleich der weiterführenden Information.
S-EDV – LMCache: Ungepatchte RCE trifft erreichbare Cache-Server
Der Beitrag erklärt konkret, wie der nicht authentifizierte ZeroMQ-Dienst und pickle.loads bei einer präparierten Nachricht eine Remote-Code-Ausführung ermöglichen.
https://s-edv.com/news/lmcache-ungepatchte-rce-multiprocess-cache-server
NetApp – KV Cache Offloading mit NetApp
Die technische Anleitung zeigt, wie LMCache KV-Cache-Blöcke über GPU, CPU und gemeinsamen Speicher verteilt, zwischen mehreren vLLM-Instanzen wiederverwendet und den Multiprocess-Modus einordnet.
https://docs.netapp.com/de-de/netapp-solutions-ai/software/ai-kv-cache-offloading-netapp.html
Digital Magazin – LMCache-Sicherheitslücke: Laut JFrog kritisch bei Netzwerk-Bindung – so prüfen Sie Ihre vLLM-Cluster bis zum Fix
Der Ratgeber nennt die betroffenen Versionen ab 0.3.9 einschließlich 0.5.5 und erläutert die Beschränkung auf localhost oder ein vertrauenswürdiges Clusternetz bis zu einem Sicherheitsupdate.
https://digital-magazin.de/lmcache-sicherheitsluecke-vllm/
