LMCache: Ungepatchte RCE trifft erreichbare Cache-Server

Unternehmen mit LMCache als eigenständigem Cache-Dienst für Sprachmodellserver sollten heute die Netzwerkbindung ihres Multiprocess-Servers prüfen. Die am 7. Oktober 2026 veröffentlichte Schwachstelle CVE-2026-105192 erlaubt Codeausführung ohne Anmeldung, sobald ein Angreifer den ZeroMQ-Transport erreicht. Nach dem Advisory von JFrog war zu diesem Zeitpunkt kein korrigiertes Release verfügbar.

Die Dringlichkeit hängt an der Betriebsart: Ein über eine routbare Adresse erreichbarer Multiprocess-Dienst ist akut abzusichern. Eine ausschließlich im vLLM-Prozess eingebettete LMCache-Instanz öffnet diesen Port dagegen nicht. Die standardmäßige Bindung an localhost verhindert den Zugriff von anderen Rechnern, beseitigt aber nicht den fehlerhaften Verarbeitungspfad.

Was ist passiert?

JFrog-Forscher Yuval Moravchick beschreibt eine unsichere Deserialisierung im Nachrichtentransport. Der Multiprocess-Modus verwendet einen nicht authentifizierten ZeroMQ-Socket, über den Worker Cache-Blöcke registrieren und austauschen. Bei bestimmten msgpack-Daten ruft DeviceIPCWrapper.Deserialize die Python-Funktion pickle.loads auf. Pickle kann beim Einlesen präparierter Daten Code ausführen.

Entscheidend ist die Reihenfolge: Die gefährliche Verarbeitung erfolgt bereits beim Dekodieren der Argumente, bevor der eigentliche Handler die Anfrage bearbeitet. Eine einzelne manipulierte Nachricht genügt laut JFrog. Ein späterer Typfehler im Serverprotokoll bedeutet deshalb nicht, dass die Ausführung verhindert wurde. Das Advisory enthält einen öffentlichen Machbarkeitsnachweis; dieser wurde für die redaktionelle Prüfung nicht ausgeführt.

Wer ist betroffen?

JFrog nennt den Verarbeitungspfad ab LMCache 0.3.9. Er sei in der aktuellen stabilen PyPI-Version 0.5.5, in den Vorabversionen von 0.5.6 bis einschließlich 0.5.6rc3 sowie im Entwicklungszweig mit Stand 7. Oktober vorhanden. Die CVE-Daten erfassen Versionen ab 0.3.9 ohne festgelegte korrigierte Obergrenze. Aus diesen Angaben lässt sich keine sichere Folgeversion ableiten.

• Besonders relevant sind eigenständige LMCache-Multiprocess-Server mit ZeroMQ-Transport und einer Bindung an eine routbare Adresse.
• Einzelrechner mit unveränderter localhost-Bindung sind über diesen Port nicht von anderen Rechnern erreichbar.
• LMCache ausschließlich innerhalb eines vLLM-Prozesses öffnet den beschriebenen Transportport nicht.
• Ein reiner vLLM-Betrieb ohne diese LMCache-Komponente ist nicht Gegenstand dieser Schwachstelle.

Auch Beispielkonfigurationen verdienen Kontrolle: Das offizielle Kubernetes-DaemonSet im Tag v0.5.5 setzt hostNetwork: true und --host 0.0.0.0. Es verwendet Port 6555, während JFrog für den Standardtransport Port 5555 nennt. Eine Inventarsuche ausschließlich nach 5555 würde daher potenziell erreichbare Installationen übersehen.

Wie kritisch ist das?

JFrog bewertet die routbar erreichbare Konfiguration mit CVSS 3.1 von 9,8. Weder Zugangsdaten noch eine Benutzeraktion sind für den beschriebenen Angriff erforderlich. Der Code läuft mit den Rechten des LMCache-Prozesses, laut JFrog in offiziellen Container-Images als root. Das ist nicht automatisch ein belegter Container-Ausbruch oder eine Übernahme des Hosts, erhöht aber den möglichen Schaden innerhalb der gewährten Berechtigungen.

Eine aktive Angriffskampagne ist in den geprüften Quellen nicht belegt. Der CVE-Datensatz enthält eine CISA-ADP-Einschätzung mit „Exploitation: none“ vom 7. Oktober. Das ist keine Garantie, dass keine Angriffe stattfinden. Öffentlich verfügbarer PoC und bestätigter Verarbeitungspfad rechtfertigen die sofortige Prüfung exponierter Systeme auch ohne Nachweis laufender Ausnutzung.

Was sollten Admins jetzt tun?

• Zuerst LMCache-Version, Multiprocess-Betriebsart, Startargumente, tatsächlich gebundene Adresse und Transportport im Inventar erfassen.
• Bei erreichbaren Diensten den Zugriff aus Internet, Client-Netzen und anderen nicht vertrauenswürdigen Segmenten unverzüglich unterbinden.
• Wo die Architektur es erlaubt, den Multiprocess-Transport auf localhost beschränken statt eine routbare Adresse mit --host zu setzen.
• Bei verteiltem Betrieb notwendige Cache-Verbindungen eng begrenzen. Auch ein erlaubter oder kompromittierter Cluster-Rechner kann den anfälligen Port weiter angreifen.
• Prozessbenutzer, Container-Berechtigungen und eingebundene Geheimnisse kontrollieren. Weniger Rechte begrenzen Folgen, reparieren jedoch keine unsichere Deserialisierung.
• Netzwerkaufzeichnungen und Prozessereignisse auf unerwartete Verbindungen und gestartete Befehle prüfen. Das Advisory liefert keine verlässliche nachträgliche Erkennung eines erfolgreichen Angriffs.
• Projektmeldungen und Releases beobachten. Ein Wechsel auf 0.5.6rc3 oder einen ungeprüften Entwicklungsstand ist nach den vorliegenden Angaben kein belegter Fix.

Einordnung für Unternehmen

Betroffen ist eine spezielle Infrastrukturkomponente, nicht pauschal jeder KI-Dienst. Für kleine Unternehmen ohne selbst betriebenen LMCache-Multiprocess-Server entsteht daraus kein eigener Patchauftrag. Bei internem oder extern betreutem GPU-Serving muss dagegen geklärt werden, wer den Cache betreibt und welche Systeme ihn erreichen. Ein geschützter HTTP-Endpunkt des Sprachmodellservers schützt nicht automatisch den separaten ZeroMQ-Transport.

Passende Anleitungen auf S-EDV

• Netzwerksegmentierung mit VLANs und Firewall-Regeln: Hintergrund zur Begrenzung von Verbindungen zwischen Client- und Serverzonen.
• Docker Compose mit weniger Rechten betreiben: Ergänzende Schutzmaßnahmen für Container, kein Ersatz für einen LMCache-Fix.

Quellen

• JFrog-Advisory vom 7. Oktober 2026: Primärquelle zu Technik, Versionen und Übergangsmaßnahmen.
• CVE-Datensatz zu CVE-2026-105192: Versionsbeginn, CVSS und CISA-ADP-Einordnung.
• Offizielles LMCache-Kubernetes-Beispiel für v0.5.5: Netzwerkbindung und abweichender Port.
• Bericht von The Hacker News vom 7. Oktober: Ergänzende redaktionelle Einordnung.