Remote Code Execution in LMCache: Risiko für LLM-Clustern und Multi-Tenant-Umgebungen

Die kritische Schwachstelle CVE-2026-105192 in LMCache, das zur Beschleunigung von Servern großer Sprachmodelle wie vLLM verwendet wird, ermöglicht einem nicht authentifizierten entfernten Angreifer die Ausführung beliebigen Codes auf dem Cache-Server, wenn der Multiprozessmodus aktiviert ist; ein Patch ist derzeit nicht verfügbar. Organisationen, die LMCache mit netzwerkseitigem Zugriff auf den ZeroMQ‑Socket einsetzen, sollten diesen umgehend in ein lokales oder vertrauenswürdiges Segment verlagern und die Konfigurationen ihrer Kubernetes-Deployments überprüfen.

Technische Details der Schwachstelle

Die Schwachstelle CVE-2026-105192 betrifft LMCache ab Version 0.3.9 bis einschließlich der stabilen Version 0.5.5 sowie die Release-Kandidaten von 0.5.6 und den aktuellen Entwicklungszweig. Die Beschreibung der CVE ist in der CVE-Datenbank veröffentlicht (CVE-Eintrag CVE-2026-105192), ein formaler Eintrag in der NVD könnte nach dem Muster NVD CVE-2026-105192 verfügbar sein, und eine technische Analyse findet sich im Sicherheitshinweis von JFrog (JFrog JFSA-2026-001694382).

Zentrale technische Punkte:

• Die Schwachstelle tritt im multiprocess mode von LMCache auf, in dem der Cache als separater Server läuft und die LLM-Workerprozesse über die ZeroMQ-Bibliothek eine Verbindung zu ihm herstellen. Der Modus ist in der offiziellen LMCache-Dokumentation beschrieben: multiprocess mode.
• Der LMCache-Server lauscht standardmäßig nur auf localhost. Das Risiko entsteht, wenn der Betreiber explizit eine routbare Adresse angibt (etwa in einem Cluster über mehrere Knoten) und damit den ZeroMQ‑Socket aus dem Netzwerk erreichbar macht.
• Im Multiprozessmodus existiert ein Nachrichtentyp, der serverseitig über den Python-Mechanismus pickle deserialisiert wird, bevor der Nachrichtentyp geprüft wird. Der entsprechende Code ist im LMCache-Repository ersichtlich (ipc_wrapper.py).
• Da:
  • auf dem ZeroMQ‑Socket keine Authentifizierung erfolgt;
  • das pickle-Format die Ausführung beliebigen Codes während der Deserialisierung zulässt;
  • die Prüfung des Nachrichtentyps nach dem Entpacken der Daten erfolgt, —

  kann jeder entfernte Client, der eine Verbindung zu diesem Socket aufbauen kann, eine speziell präparierte Nachricht senden und dadurch die Ausführung eigenen Codes mit den Rechten des LMCache-Prozesses erreichen.

• Nach Angaben von JFrog läuft der Cache-Prozess in den offiziellen Container-Images von LMCache mit root-Rechten, was das Deserialisierungsproblem zu einer vollständigen Übernahme des Knotens eskalieren lässt.

Eine Besonderheit der Konfiguration verschärft das Risiko: Im offiziellen Beispiel für ein Kubernetes-Deployment des Multiprozess-Servers von LMCache (lmcache-daemonset.yaml) ist der Server so konfiguriert, dass er auf allen Netzwerkschnittstellen lauscht und nicht nur auf localhost. Ein solches Beispiel wird häufig unverändert in produktive Cluster übernommen, was die Exponierung wahrscheinlicher macht.

Die LMCache-Entwickler haben bislang keinen offiziellen Sicherheitshinweis im Bereich Sicherheitshinweise veröffentlicht, und eine fehlerbereinigte Release-Version ist nicht verfügbar. Eine Ausnutzung der Schwachstelle „in the wild“ wird in der Ausgangsanalyse nicht beobachtet, aber der Angriffsvektor ist trivial, erfordert keine Authentifizierung und ist nicht an eine bestimmte Version von Python oder ZeroMQ gebunden, was eine praktische Ausnutzung äußerst realistisch macht.

Bedrohungskontext: wiederkehrendes ShadowMQ-Muster

Die JFrog-Forscher weisen darauf hin, dass der logische Fehler mit einer zuvor gefundenen Reihe von Schwachstellen in der Infrastruktur für KI-Inferenz übereinstimmt, die unter dem Arbeitstitel ShadowMQ zusammengefasst wurden: Daten von einem nicht authentifizierten Netzwerksocket werden direkt per pickle deserialisiert. Es handelt sich nicht um einen Einzelfehler eines bestimmten Projekts, sondern um ein persistentes Anti-Pattern beim Design von Hochleistungs-IPC- und Netzwerkkomponenten im AI-Stack.

Bemerkenswert ist, dass LMCache nicht die einzige Komponente in der Kette ist. Im vLLM-Ökosystem wurde bereits eine separate Denial-of-Service-Schwachstelle CVE-2026-105756 behoben, bei der eine einzelne Anfrage mit einem fehlerhaften Wert von cache_salt den Engine-Prozess zum Absturz bringen konnte, wenn der LMCache-Multiprozess-Connector verwendet wurde. Details finden sich im Sicherheitshinweis des vLLM-Projekts (GHSA-2823-qmq8-rwvj). Dort geht es nur um das Abstützen des Prozesses und nicht um Codeausführung, aber in der Summe unterstreicht dies: Die Kombination aus LLM-Engine + Cache + Interprozesskommunikation ist zu einer neuen Angriffsfläche geworden.

Weitere Tickets im GitHub-Repository von LMCache (z. B. Issue #5507 und Issue #5508) beschreiben mutmaßliche Probleme mit nicht authentifiziertem Zugriff auf Cache-Daten und Befehle verschiedener Netzwerkdienste. Diese wurden jedoch bisher von den Maintainern weder bestätigt noch mit einer CVE versehen oder behoben. Für eine praktische Risikobewertung sollten sie eher als Indikator für den allgemeinen Vertrauens- und Sicherheitszustand des Produkts betrachtet werden und nicht als formal verifizierte Schwachstellen.

Bewertung der Auswirkungen auf Organisationen

Das höchste Risiko besteht in Umgebungen, in denen die folgenden Faktoren zusammenkommen:

• Einsatz von LMCache im multiprocess mode mit netzwerkseitiger Erreichbarkeit des ZeroMQ‑Sockets von anderen Hosts (einschließlich Clustern über mehrere Knoten hinweg);
• eine Microservice- oder Kubernetes-Architektur, die nach dem Beispiel des offiziellen DaemonSets ausgerollt ist und den Server an „alle Schnittstellen“ bindet;
• Ausführung des LMCache-Containers mit root-Rechten oder mit Zugriff auf gemeinsame Volumes, die Zugriffstoken, Konfigurationen der LLM-Engine oder Protokolle von Nutzeranfragen enthalten.

Mögliche Folgen bei erfolgreicher Ausnutzung:

• Vollständige Kompromittierung des Knotens mit LMCache: Installation von Backdoors, Kryptomining, Nutzung des Knotens als Ausgangspunkt für weiteres Lateral Movement.
• Kompromittierung vertraulicher Daten:
  • Zugriff auf den Inhalt des Caches (Fragmente von Prompts, Modellantworten, Zwischenrepräsentationen);
  • Zugriff auf das Dateisystem des Containers/Knotens mit möglicher Offenlegung von Geheimnissen des Orchestrators und der LLM-Plattform.
• Beeinträchtigung der Verfügbarkeit von AI-Services: beliebige Befehle können Prozesse stoppen, Ressourcen verbrauchen, Konfigurationen verändern oder den Cache als Kanal für weitere Angriffe nutzen.

Besonders gefährdet sind:

• Anbieter von LLM-Services und interne AI-Plattformen mit Multi-Tenant-Modell;
• Cloud-Umgebungen und große Cluster, in denen sich der Cache über mehrere Knoten erstreckt und sich Netzwerk-Vertrauensdomänen überschneiden können;
• alle Umgebungen, in denen LMCache ohne strikte Netzsegmentierung betrieben wird (gemeinsame Cluster-Netze, Zugriff aus Hilfsservices, Entwicklungs-Namespaces usw.).

Praktische Empfehlungen zum Schutz

1. Sofortige Priorisierung und Änderung der Netzexponierung

• Identifizieren Sie alle LMCache-Deployments:
  • über Abhängigkeiten von LLM-Plattformen (z. B. vLLM),
  • über Images in Container-Registern, die den Namen lmcache enthalten,
  • über Kubernetes-Konfigurationen, die das DaemonSet-Beispiel aus dem offiziellen Repository verwenden.
• Für alle Instanzen des Multiprozess-Servers:
  • beschränken Sie die lausche Adresse auf localhost oder streng vertrauenswürdige Subnetze des Clusters;
  • schließen Sie die Möglichkeit von Verbindungen aus Benutzernetzsegmenten, allgemeinen VPN-Zonen und aus dem Internet aus.
• Setzen Sie Kubernetes-Network-Policies, separate Security-Gruppen oder Firewalls ein, um den Kreis der Hosts, die Zugriff auf den ZeroMQ‑Socket haben, zu minimieren. Dabei sollte von der Annahme ausgegangen werden: Jeder Host mit Netzwerkzugang kann Remote Code Execution durchführen.

2. Privilegien reduzieren und striktes Runtime-Controlling

• Bauen Sie LMCache-Container neu oder überschreiben Sie deren Konfiguration, sodass der Prozess nicht mit root-Rechten läuft:
  • legen Sie einen nicht privilegierten Benutzer im Dockerfile oder im PodSpec fest;
  • deaktivieren Sie unnötige Kernel-Capabilities und den Zugriff auf hostPath-Volumes.
• Aktivieren Sie eine Verhaltenskontrolle der Container (seccomp, AppArmor oder vergleichbare Mechanismen), um Systemaufrufe zu beschränken und Post-Exploitation zu erschweren.

3. Patches und Versionen begleitender Komponenten

• Aktualisieren Sie vLLM auf Version 0.30.0 oder neuer, um die DoS-Schwachstelle CVE-2026-105756 im LMCache-Connector zu beseitigen (vLLM-Sicherheitshinweis).
• Verfolgen Sie die Veröffentlichung einer bereinigten LMCache-Version im Bereich Sicherheitshinweise und in der Dokumentation zum multiprocess mode; planen Sie ein beschleunigtes Update, sobald ein Patch verfügbar ist.

4. Monitoring und Indikatoren möglicher Ausnutzung

JFrog veröffentlicht keine expliziten Kompromittierungsindikatoren (IP-Adressen, Hashes bösartiger Images usw.), dennoch können folgende Schritte unternommen werden:

• Analysieren Sie Netzwerk- und Kubernetes-Logs im Hinblick auf:
  • Verbindungen zum Port des LMCache-Multiprozess-Servers aus untypischen Subnetzen oder Namespaces;
  • ungewöhnliches Wachstum der Anzahl registrierter Worker oder unerwartete Neustarts von Pods mit LMCache.
• Überprüfen Sie Knoten, auf denen LMCache läuft, auf:
  • unbekannte Prozesse und Cron-Jobs;
  • Änderungen an Container-Images, Konfigurations-Volumes und Binaries.
• Aktivieren Sie zusätzlichen Audit für Befehle und Systemaufrufe der LMCache-Container, bis ein offizieller Fix verfügbar ist.

Das entscheidende Fazit: Bis ein Patch für CVE-2026-105192 verfügbar ist, bleibt der einzige wirksame Schutz ein striktes Einschränken des Netzwerkzugriffs auf den Multiprozess-Server von LMCache und der Verzicht darauf, ihn mit root-Rechten zu starten. Der erste Schritt sollte eine Inventarisierung aller LMCache-Deployments und die sofortige Umstellung des ZeroMQ‑Sockets auf lokale oder streng kontrollierte Netzwerksegmente sein.