Die verteilte Architektur von LMCache weist eine kritische Schwachstelle auf, über die nicht authentifizierte Netzwerk-Clients mithilfe unsicherer Python-Deserialisierung Code ausführen können. Die Schwachstelle CVE-2026-105192 erhielt einen CVSS-v3.1-Score von 9,8 KRITISCH.
JFrog, die CVE Numbering Authority (CNA) für diese Schwachstelle, veröffentlichte und aktualisierte den CVE-Eintrag am 7. Oktober 2026. Die Sicherheitsforscher des Unternehmens legten die Schwachstelle noch am selben Tag offen und nannten Yuval Moravchick als Entdecker.
Das Risiko hängt von der Konfiguration ab. LMCache bindet den betroffenen Transport standardmäßig an localhost. Für Bereitstellungen mit mehreren Knoten können Betreiber ihn jedoch auch an eine über das Netzwerk erreichbare Adresse binden. Zum Zeitpunkt der Offenlegung war laut Bericht noch keine gepatchte LMCache-Version verfügbar. Zudem gab es keine verifizierten Hinweise darauf, dass Angreifer die Schwachstelle in produktiven Systemen ausgenutzt hatten.
Vor der Authentifizierung gelangt eine Netzwerknachricht zu pickle.loads
LMCache ist eine Open-Source-Caching-Software, die das Bereitstellen von Systemen mit großen Sprachmodellen wie vLLM beschleunigen soll. Betroffen ist der Multiprozessmodus, auch verteilter Modus genannt. Dabei läuft LMCache als separater Cache-Server, mit dem Worker über ZeroMQ kommunizieren.
Laut dem CVE-Program-Eintrag öffnet der Server einen ZeroMQ-ROUTER-Socket, über den sich Worker registrieren und KV-Cache-Blöcke austauschen. Der Socket authentifiziert Clients nicht.
Die Nachrichten werden mit msgpack kodiert. Beim Dekodieren wird der Erweiterungscode 1 an DeviceIPCWrapper.Deserialize übergeben. Diese Funktion ruft Python-pickle.loads mit vom Absender kontrollierten Daten auf. Entscheidend ist, dass die Deserialisierung erfolgt, während der Server noch die Anfrageargumente verarbeitet – also bevor der zuständige Nachrichten-Handler ausgeführt wird.
Ein Angreifer, der den Transport erreichen kann, kann daher mit einer präparierten ZeroMQ-DEALER-Nachricht Codeausführung unter dem Benutzerkonto auslösen, unter dem LMCache läuft. Dafür sind weder Zugangsdaten noch eine Interaktion durch einen Nutzer erforderlich.
Der zugewiesene Vektor lautet:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Der Eintrag stuft die Schwachstelle sowohl als CWE-306 (fehlende Authentifizierung für eine kritische Funktion) als auch als CWE-502 (Deserialisierung nicht vertrauenswürdiger Daten) ein.
Ob der Dienst über das Netzwerk erreichbar ist, hängt von der Bindung an Port 5555 ab
Der betroffene Transport verwendet standardmäßig Port 5555. Er lauscht nur auf localhost, sofern der Betreiber nicht über --host eine über das Netzwerk erreichbare Adresse angibt. Mit dieser Konfiguration können Worker auf anderen Knoten eine Verbindung herstellen.
Eine Installation mit der standardmäßigen lokalen Bindung ist über diese Schnittstelle also nicht von anderen Hosts aus erreichbar. Anders sieht es aus, wenn der Dienst an eine Cluster-Adresse, alle Schnittstellen oder einen anderen über das Netzwerk zugänglichen Endpunkt gebunden wird.
Laut dem ursprünglichen Bericht startet die Kubernetes-Beispielbereitstellung von LMCache den Server auf allen Netzwerkschnittstellen. Der Bericht weist außerdem darauf hin, dass eine in einen einzelnen vLLM-Prozess eingebettete LMCache-Instanz den betroffenen Port nicht öffnet.
JFrog zufolge laufen die offiziellen LMCache-Container-Images mit Root-Rechten. Eine erfolgreiche Ausnutzung könnte dort also Code mit Root-Rechten in der Umgebung ausführen, in der der Prozess läuft. Das gilt nicht automatisch für Installationen, bei denen LMCache mit einem Konto mit geringeren Rechten ausgeführt wird. Ebenso lässt sich daraus nicht ableiten, auf welche Host-Ressourcen ein bestimmter Container zugreifen kann.
In den zitierten Einträgen gibt es keine verifizierten Hinweise auf eine Ausnutzung in freier Wildbahn. Der technische Angriffsweg ermöglicht zwar Remote Code Execution, sofern der Socket erreichbar ist. Das ist jedoch nicht gleichbedeutend mit einem Nachweis für einen tatsächlichen Angriff.
Angaben zu den Versionen decken unterschiedliche LMCache-Bereiche ab
Der offizielle CVE-Eintrag führt LMCache 0.3.9 als betroffen auf, nennt aber keine Obergrenze für die Versionsnummer. In den Referenzen wird auf anfälligen Code in v0.3.9 und v0.5.5 verwiesen.
Der Nachrichtenbericht nennt einen größeren Bereich: Versionen von 0.3.9 bis 0.5.5, außerdem Release Candidates von 0.5.6 und den Entwicklungszweig. Dem Bericht zufolge war 0.5.5 die neueste stabile Version; Version 0.3.9 sei im Oktober 2025 veröffentlicht worden.
Die Angaben stützen sich auf unterschiedliche Beleglagen. Der CNA-Eintrag bestätigt, dass Version 0.3.9 betroffen ist. Die weitergehenden Aussagen zu Versionen und Entwicklungszweig stammen hingegen aus dem Nachrichtenbericht und nicht aus einer vollständigen Angabe des betroffenen Versionsbereichs im vorliegenden CVE-Eintrag.
Zum Zeitpunkt der Offenlegung war keine korrigierte LMCache-Version bekannt. Der CVE-Eintrag nennt keine gepatchte Version. Auch laut Bericht war am 7. Oktober 2026 noch keine korrigierte Version verfügbar.
Netzwerkisolation ist die wichtigste Sofortmaßnahme
Die von JFrog ausgesprochenen und im Bericht wiedergegebenen Übergangsempfehlungen zielen darauf ab, zu verhindern, dass nicht vertrauenswürdige Systeme den ZeroMQ-Transport erreichen:
- Den Multiprozess-Server nicht an eine über das Netzwerk erreichbare Adresse binden, solange keine korrigierte Version verfügbar ist.
- Den Dienst auf localhost beschränken, wenn kein verteilter Betrieb erforderlich ist.
- Wenn Worker aus der Ferne eine Verbindung herstellen müssen, den Zugriff auf ein vertrauenswürdiges Clusternetzwerk beschränken.
- Den Zugriff auf Port 5555 per Firewall regeln und nur erforderliche Peers zulassen.
Firewall-Regeln schränken die erreichbare Angriffsfläche ein, beseitigen aber nicht die unsichere Deserialisierung. Jeder zugelassene oder kompromittierte Host, der eine Verbindung zum Socket herstellen kann, könnte weiterhin eine bösartige Nachricht übermitteln.
Betreiber sollten außerdem prüfen, unter welchem Benutzerkonto der LMCache-Prozess läuft, und dessen Rechte so weit wie möglich beschränken. Das kann die möglichen Folgen einer Ausnutzung mindern, ersetzt aber nicht die Korrektur des anfälligen Codes.
Dem Bericht zufolge enthielt die Empfehlung von JFrog keine Anleitung, wie sich eine bereits erfolgte Ausnutzung feststellen lässt. Auch die zitierten Informationen enthalten weder Indikatoren für eine Kompromittierung noch eine forensische Abfrage zu CVE-2026-105192. Diese Feststellung beschränkt sich auf die verfügbaren Berichte und belegt nicht, dass es an anderer Stelle keine entsprechenden Hinweise gibt.
Eine separate vLLM-Schwachstelle kann EngineCore zum Absturz bringen
Ein verwandtes, technisch jedoch eigenständiges Problem betrifft vLLM-Bereitstellungen, die den integrierten LMCache-MP-KV-Connector verwenden. CVE-2026-105756 ermöglicht es, mit einem fehlerhaften Wert für cache_salt eine nicht abgefangene Ausnahme auszulösen und EngineCore zu beenden.
Die Schwachstelle hat einen CVSS-v3.1-Score von 6,5 und die Einstufung „Moderat“:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Sie ist als CWE-20 (unzureichende Eingabevalidierung) und CWE-248 (nicht abgefangene Ausnahme) klassifiziert. Anders als beim RCE in LMCache verlangt der angegebene Vektor geringe Berechtigungen; betroffen ist ausschließlich die Verfügbarkeit.
Betroffene OpenAI-kompatible Modelle für Completions, Chat Completions und Responses akzeptieren jeden nicht leeren Wert für cache_salt. Der nachgelagerte LMCache-MP-IPCCacheServerKey stellt jedoch zusätzliche Anforderungen: Er weist Salts zurück, die länger als 128 Zeichen sind oder @, /, \ beziehungsweise NUL enthalten.
Diese Einschränkungen wurden nicht geprüft, bevor der Wert die Cache-Abfrage des Schedulers erreichte. Laut dem GitHub Security Advisory löst ein abgewiesener Salt einen ValueError aus, der weder auf Ebene des Connectors noch des Schedulers abgefangen wird. EngineCore behandelt die Ausnahme anschließend als fatal, wodurch der Dienst für gleichzeitig aktive Nutzer beeinträchtigt wird. Das Advisory nennt cache_salt="/" als Beispiel.
Das Problem wurde mit vLLM 0.25.1, Commit 752a3a504485, bestätigt. Es betrifft nur Installationen, bei denen der optionale LMCache-MP-Connector aktiviert ist. Dieser Connector erfordert lmcache >= 0.4.4.
Laut Beschreibung des NVD und dem allgemeinen Versionsbereich im Advisory sind Versionen vor 0.30.0 betroffen; Version 0.30.0 behebt das Problem. Ein anderes Feld im Advisory nennt jedoch >= 30.0.0 als gepatchte Version. Dieser widersprüchliche Wert sollte nicht stillschweigend als gleichbedeutend behandelt werden. Betreiber sollten die konkret eingesetzte Paketversion überprüfen. Das Advisory wurde am 23. September 2026 veröffentlicht; dem Bericht zufolge erschien vLLM 0.30.0 am 22. September.
Weitere Vorwürfe zu LMCache sind nicht bestätigt
Der Bericht beschreibt außerdem sechs weitere Sicherheitsmeldungen zu LMCache, die am 6. Oktober 2026 von einem GitHub-Konto eingereicht wurden. Darin wird der mandantenübergreifende Zugriff auf zwischengespeicherte Daten sowie der nicht authentifizierte Zugriff auf Netzwerkdienste behauptet, über die sich Befehle ausführen lassen.
Für diese Meldungen gibt es laut den zitierten Berichten weder CVE-Nummern noch eine Bestätigung durch die Maintainer oder bekannte Fehlerbehebungen. Sie stützen sich auf Behauptungen zu Proofs of Concept und sind unabhängig von CVE-2026-105192 zu betrachten.
Einer der Berichte behauptet, dass in Version 0.5.5 ein administrativer HTTP-Server auf allen Schnittstellen lauschte, während ihn Release Candidates von 0.5.6 auf localhost beschränkten. Solange die Maintainer die zugrunde liegenden Behauptungen nicht überprüft haben, sollten diese Meldungen nicht als bestätigte LMCache-Schwachstellen dargestellt werden.
Das unsichere Muster hinter CVE-2026-105192 ähnelt der Verwendung nicht authentifizierter Nachrichten mit Python-pickle, die Forscher im November 2025 unter dem Namen ShadowMQ beschrieben. Aus den Berichten geht nicht hervor, ob zwischen diesen früheren Erkenntnissen und LMCache gemeinsamer Code oder ein gemeinsamer Ursprung besteht.
