LMCache CVE-2026-105192: Ihre KI-Inferenz-Pipeline hat jetzt eine kritische ungepatchte RCE

Ihr LLM-Inferenz-Cluster lauscht auf Port 5555, und alles in diesem Netzwerk kann Code als Root ausführen

Vor zwei Wochen hat das Sicherheitsteam von JFrog eine Schwachstelle mit einem CVSS-Score von 9.8 offengelegt, der zweithöchsten möglichen Bewertung. Kein Patch. Ein öffentlicher Proof-of-Concept-Exploit. Und die betroffene Software sitzt direkt in der Inferenzschicht eines der beliebtesten Open-Source-LLM-Serving-Stacks der Welt.

Die Schwachstelle ist CVE-2026-105192, und sie steckt in LMCache: der verteilten Key-Value-Cache-Schicht, die vLLM antreibt, die Open-Source-Inferenz-Engine, die derzeit auf Tausenden von Produktions-Clustern läuft.

Dies ist kein theoretischer Fehler. Es ist ein nicht authentifizierter Remote-Code-Execution-Pfad, offengelegt am 7. Oktober 2026 im Advisory JFSA-2026-001694382, und zum Zeitpunkt dieses Artikels existiert keine behobene Version.

Was LMCache tatsächlich tut und warum es überall ist

Wenn Sie LLM-Inferenz in großem Maßstab betreiben, sind Sie LMCache wahrscheinlich schon begegnet. Es ist ein verteilter Key-Value-Cache, der KV-Cache-Blöcke speichert und wiederverwendet (die zwischengespeicherten Attention-Zustände, die den Speicherbedarf und die Latenz der LLM-Inferenz dominieren). vLLM, die Inferenz-Engine, die Organisationen von Hugging Face bis zu Unternehmen im Nahen Osten nutzen, um Open-Weight- und feinabgestimmte Modelle bereitzustellen, integriert LMCache in Multi-Node-Deployments als externe Caching-Schicht.

Die Idee: Wenn ein Worker-Prozess auf Node A einen KV-Block berechnet, kann er ihn mit Worker-Prozessen auf Node B teilen, anstatt ihn neu zu berechnen. Im verteilten Modus öffnet LMCache einen ZeroMQ-ROUTER-Socket, standardmäßig auf Port 5555, damit Worker-Prozesse sich registrieren und Cache-Blöcke über Maschinen hinweg austauschen können.

Es ist ein schneller Pfad für das LLM-Serving. Und es hat keinerlei Authentifizierung.

Die Schwachstelle: Eine Cache-Nachricht, die Ihren Code ausführt

Hier ist der Fehler, im Detail zerlegt:

1. Der Multiprozess-Transport von LMCache spricht MessagePack mit dem Extension-Code 1 für DeviceIPCWrapper
2. Beim Dekodieren leitet der Extension-Hook in lmcache/v1/multiprocess/custom_types.py eingebettete Daten an DeviceIPCWrapper.Deserialize weiter
3. Diese Funktion ruft pickle.loads auf, die unsichere binäre Deserialisierung von Python
4. Die Deserialisierung erfolgt, während der Server die Argumente von REGISTER_KV_CACHE verarbeitet, bevor der Request-Handler ausgeführt wird

Mit anderen Worten: Jede Nachricht, die den Cache-Server auf Port 5555 erreicht, kann die Ausführung von Code auf dem Host auslösen, und zwar unter dem Benutzer, unter dem der LMCache-Prozess läuft.

Der öffentliche PoC von JFrog (research.jfrog.com) demonstriert dies von Anfang bis Ende:

1. Ein Angreifer sendet eine präparierte mehrteilige MessagePack-Nachricht an Port 5555 auf jedem erreichbaren LMCache-Node
2. Die eingebettete pickle-Payload enthält ein bösartiges DeviceIPCWrapper-Objekt
3. Wenn der Server sie deserialisiert, führt die pickle-Rekonstruktion einen OS-Befehl aus
4. Der PoC schreibt die Ausgabe von id nach /tmp/zmq_pwn
5. Der Server protokolliert dann einen Typfehler: Der Handler erhält den Rückgabewert des Befehls statt des erwarteten Wrapper. Zu spät.

Der PoC bestätigt die Ausführung. Der Container läuft als Root.

Wer betroffen ist

Der anfällige Dekodierungspfad wurde in LMCache 0.3.9 eingeführt und ist in jeder Version bis 0.5.5, in allen Release Candidates bis 0.5.6rc3 und im Entwicklungszweig, der zum 7. Oktober geprüft wurde, weiterhin vorhanden. Das bedeutet:

• Jedes verteilte vLLM + LMCache-Deployment auf den Versionen 0.3.9 bis 0.5.6rc3
• Deployments, die das Flag --host verwenden, um an eine routbare IP zu binden (nicht nur localhost)
• Produktions-Cluster in Multi-GPU- oder Multi-Node-Konfigurationen, in denen Cache-Nodes über das Netzwerk erreichbar sind

JFrog hat den Score von 9.8 ausdrücklich auf die netzwerk-erreichbare Konfiguration beschränkt. Ein vLLM-Deployment auf einem einzigen Host, bei dem LMCache den betroffenen Port nicht öffnet, ist nicht anfällig. Aber wenn Sie Multi-Node-Inferenz mit routbaren Adressen aktiviert haben, und das haben die meisten realen LLM-Cluster, sind Sie betroffen.

Was Sie jetzt tun sollten

Es gibt keine gepatchte Version. Hier ist das Mitigation-Playbook:

• Port 5555 einschränken: Wenden Sie Firewall-Regeln an, damit nur die spezifischen Cache-Node-IPs in Ihrem LLM-Cluster Port 5555 erreichen können. Blockieren Sie alles andere.
• Auf localhost-Binding zurückgehen: Wenn Sie Ihr Deployment vorübergehend so umkonfigurieren können, dass LMCache nur an localhost gebunden ist, tun Sie es. Sie verlieren die Cache-Freigabe zwischen Nodes, beseitigen aber die Angriffsfläche vollständig.
• pickle durch einen sicheren Serializer ersetzen: Die langfristige Empfehlung von JFrog ist, die pickle-basierte Netzwerk-Deserialisierung durch ein sicheres Serialisierungsformat zu ersetzen (das native Typsystem von MessagePack, JSON oder protobuf) und den ZeroMQ-Transport mit CURVE, ZAP oder per-Message-HMAC-Verifizierung zu authentifizieren.
• LMCache-Versionen pinnen und überwachen: Wenn Sie auf 0.5.x sind, beobachten Sie den Release-Tracker auf eine behobene Version. Bis sie erscheint, sind die oben genannten Maßnahmen Ihre einzige Verteidigung.
• Ihre Cluster-Topologie prüfen: Prüfen Sie, welche Nodes LMCache mit einem routbaren Flag --host ausführen. Jeder davon ist ein potenzieller nicht authentifizierter RCE-Endpunkt für alles, was Port 5555 im internen Netzwerk erreichen kann.

Das größere Bild: KI-Infrastruktur ist jetzt Ihre Angriffsfläche

LMCache CVE-2026-105192 ist nicht die erste ungepatchte kritische Schwachstelle im KI-Serving-Stack, aber sie ist eine der folgenreichsten, weil die Software allgegenwärtig ist. Open-Source-Inferenz-Engines wie vLLM sind zu tragenden Komponenten in Produktions-LLM-Deployments in der gesamten Region geworden, und ihre Abhängigkeitsketten, einschließlich Cache-Schichten, Tokenizer und Orchestrierungs-Tooling, haben sich schneller entwickelt als die Sicherheitsüberprüfung.

Für die GCC-Region, in der souveräne KI-Initiativen und Enterprise-LLM-Deployments an Fahrt aufnehmen, ist dies eine Erinnerung daran, dass "Sicherheit der KI-Infrastruktur" längst kein Nischenthema mehr ist. Die Modelle sind nur die Compute-Schicht. Die eigentliche Angriffsfläche ist alles um sie herum: der Cache, der Orchestrator, der Container, das Netzwerk.

Bei Aratech bauen wir die Context-Engine und die operativen Loops, die genau auf dieser Art von Infrastruktur aufsetzen. Wir denken in den Kategorien: Was kann erreicht werden, wer kann es erreichen, und was passiert, wenn eine nicht vertrauenswürdige Nachricht auf Port 5555 eintrifft, an die niemandes Zugangsdaten angehängt sind.

Das ist die Denkweise, über die jedes Team, das LLM-Inferenz in großem Maßstab betreibt, jetzt nachdenken sollte.