Betroffen ist der sogenannte Multiprocess-Modus von LMCache, in dem der Cache als eigenständiger Server läuft und LLM-Worker ihn über die Messaging-Bibliothek ZeroMQ ansprechen. Eine einzige Netzwerknachricht an diesen Server genügt, um Befehle mit den Rechten des Nutzers auszuführen, unter dem der LMCache-Prozess läuft. Auf den offiziellen Container-Images des Projekts ist das laut JFrog der Root-Nutzer. Entdeckt wurde der Fehler von Yuval Moravchick aus dem Sicherheitsforschungsteam von JFrog.
Der ZeroMQ-Socket, über den sich Worker-Prozesse registrieren und zwischengespeicherte Daten austauschen, verlangt keinerlei Authentifizierung. Ein Nachrichtentyp wird mit pickle entpackt – einem Python-Format, das Code transportieren und beim Dekodieren ausführen kann. Der Server entpackt die Daten bereits beim Einlesen der Argumente, also noch bevor der Nachrichtentyp überhaupt geprüft wird. Eine präparierte Nachricht bringt so den Code des Absenders zur Ausführung.
Die Lücke steckt in LMCache ab Version 0.3.9, erschienen im Oktober 2025, bis einschließlich 0.5.5, der aktuellen stabilen Fassung. Auch die Release Candidates von 0.5.6 und der Entwicklungszweig sind betroffen.
Ob ein Server von außen erreichbar ist, hängt an einer einzigen Einstellung. Standardmäßig lauscht der Multiprocess-Server nur auf dem lokalen Rechner; andere Hosts kommen dann nicht heran. Erreichbar wird er erst, wenn Betreiber ihn mit einer routbaren Adresse starten – wie es etwa bei Multi-Node-Deployments üblich ist, die einen Cache über mehrere Maschinen teilen. Das mitgelieferte Kubernetes-Beispiel-Deployment von LMCache startet den Server genau so und lässt ihn auf allen Netzwerkschnittstellen lauschen. Läuft LMCache dagegen innerhalb eines einzelnen vLLM-Prozesses, wird der Port gar nicht erst geöffnet.
Solange kein Patch vorliegt, rät JFrog Betreibern, dem Multiprocess-Server keine routbare Adresse zuzuweisen und den Port auf dem lokalen Rechner oder in einem vertrauenswürdigen Cluster-Netz zu belassen. Eine Firewall, die den Zugriff auf den Port einschränkt, senkt das Risiko, beseitigt es aber nicht: Jeder Host, der noch eine Verbindung aufbauen kann, kann auch Code ausführen. LMCache selbst hat zu der Schwachstelle keine Sicherheitsmitteilung veröffentlicht. Die Veröffentlichung von JFrog nennt zudem keine Möglichkeit, festzustellen, ob ein Server bereits angegriffen wurde.
Unabhängig davon eröffnete ein GitHub-Nutzer am 6. Oktober, einen Tag vor der Veröffentlichung von CVE-2026-105192, sechs weitere Sicherheitsmeldungen zu LMCache. Darin wird unauthentifizierter Zugriff auf zwischengespeicherte Daten unterschiedlicher Mandanten behauptet sowie auf mehrere Netzwerkdienste, die Befehle ohne Anmeldung ausführen. Die Meldungen stammen alle von einem einzigen Konto, stützen sich auf Proof-of-Concept-Behauptungen und verfügen weder über eine CVE-Nummer noch über eine Bestätigung der Maintainer oder einen Fix. Eine davon bezieht sich auf eine Voreinstellung, die inzwischen geändert wurde: Ein administrativer HTTP-Server, der in 0.5.5 noch auf allen Netzwerkschnittstellen lauschte, hört in den Release Candidates von 0.5.6 nur noch lokal.
Ein verwandter Fehler in vLLM ist bereits behoben. Vor Version 0.30.0, veröffentlicht am 22. September, konnte eine einzelne Anfrage mit einem fehlerhaften cache_salt-Wert die Engine zum Absturz bringen, sofern das Deployment den Multiprocess-Connector von LMCache nutzt. Dieser Denial-of-Service-Fehler wird als CVE-2026-105756 geführt und mit 6,5 bewertet; Codeausführung ermöglicht er nicht.
Der zugrunde liegende Fehler – Daten von einem unauthentifizierten Netzwerk-Socket direkt an pickle zu übergeben – ist derselbe, den Forscher im November 2025 in mehreren anderen KI-Inferenz-Frameworks fanden und unter dem Namen ShadowMQ zusammenfassten. Ob der Code von LMCache eine gemeinsame Herkunft mit jenen Projekten hat, ist nicht geklärt.