Kritische, ungepatchte Schwachstelle in LMCache ermöglicht Remote-Code-Ausführung

Sicherheitsforscher haben eine kritische Schwachstelle in LMCache identifiziert, einer Open-Source-Beschleunigungsschicht für Server großer Sprachmodelle wie vLLM. Die am 7. Oktober von JFrog offengelegte Lücke ermöglicht es nicht authentifizierten Angreifern, beliebigen Code auf betroffenen Systemen auszuführen. Zum Zeitpunkt dieses Berichts ist keine korrigierte Softwareversion verfügbar, sodass Betreiber auf Änderungen der Netzwerkkonfiguration zum Schutz angewiesen sind.

Was passiert ist

Die als CVE-2026-105192 geführte Schwachstelle weist einen Schweregrad von 9,8 von 10 Punkten auf. Sie betrifft LMCache-Versionen ab 0.3.9, veröffentlicht im Oktober 2025, bis hin zur neuesten stabilen Version 0.5.5. Das Problem besteht auch in den Release-Kandidaten der Version 0.5.6 und im aktuellen Entwicklungszweig fort. Das Sicherheitsteam von JFrog unter der Leitung von Yuval Moravchick entdeckte, dass eine einzelne präparierte Netzwerknachricht eine Remote-Code-Ausführung auf dem Cache-Server auslösen kann.

Das Risikoniveau hängt stark von der Bereitstellungskonfiguration ab. Standardmäßig lauscht der LMCache-Multiprozess-Server nur auf dem lokalen Rechner, was externen Zugriff verhindert. Viele Multi-Node-Bereitstellungen erfordern jedoch, dass der Server auf einer routbaren Adresse lauscht, um gecachte Daten zwischen Maschinen zu teilen. Die eigene Kubernetes-Beispielbereitstellung von LMCache konfiguriert den Server so, dass er auf jeder Netzwerkschnittstelle lauscht, was ihn effektiv dem Clusternetzwerk aussetzt. In diesen Konfigurationen kann jeder Host, der den Port erreichen kann, die Schwachstelle ausnutzen.

Verschärfend kommt hinzu, dass die offiziellen Container-Images für LMCache den Prozess als Root-Benutzer ausführen. Dies bedeutet, dass eine erfolgreiche Ausnutzung dem Angreifer volle administrative Rechte auf dem Host einräumt. JFrog merkt an, dass Firewalls zwar die Exposition begrenzen können, das Risiko aber nicht vollständig eliminieren, wenn ein vertrauenswürdiger Host innerhalb des zulässigen Bereichs kompromittiert wird. Derzeit gibt es keine Methode, um festzustellen, ob ein Server bereits angegriffen wurde.

Wie es funktioniert

Die Ursache liegt darin, wie LMCache die Interprozesskommunikation unter Verwendung der Messaging-Bibliothek ZeroMQ handhabt. Der Multiprozess-Server öffnet einen Socket, über den Worker-Prozesse sich registrieren und gecachte Daten austauschen können, doch diesem Socket fehlt jeglicher Authentifizierungsmechanismus. Wenn eine Nachricht eingeht, verwendet der Server das Python-Modul pickle, um die Daten zu deserialisieren. Pickle ist bekanntlich unsicher für nicht vertrauenswürdige Daten, da es während des Decodierungsprozesses beliebigen Code ausführen kann.

Entscheidend ist, dass der Server die Pickle-Daten entpackt, während er noch die Nachrichtenargumente liest, bevor er den Nachrichtentyp überprüft. Diese Reihenfolge der Operationen ermöglicht es einem Angreifer, eine bösartige Nutzlast zu senden, die sofort beim Empfang ausgeführt wird. Der Code läuft mit denselben Berechtigungen wie der LMCache-Prozess, der, wie erwähnt, in containerisierten Umgebungen oft Root-Rechte hat. Dieses Muster ähnelt einer Gruppe von Schwachstellen namens ShadowMQ, die im November 2025 in anderen KI-Inferenz-Frameworks identifiziert wurden, obwohl eine direkte Codeverbindung nicht nachgewiesen wurde.

Wichtige Details

• CVE-Identifier: CVE-2026-105192, eingestuft mit 9,8/10 im Schweregrad.
• Betroffene Versionen: LMCache 0.3.9 bis 0.5.5, sowie Release-Kandidaten von 0.5.6 und Dev-Zweige.
• Angriffsvektor: Nicht authentifizierte Netzwerknachricht über ZeroMQ-Socket im Multiprozess-Modus.
• Ursache: Unsichere Deserialisierung mittels Python pickle vor Validierung des Nachrichtentyps.
• Berechtigungsebene: Code wird als LMProcess-Benutzer ausgeführt, welcher in offiziellen Containern Root ist.
• Patch-Status: Derzeit ist keine korrigierte Version verfügbar.

Warum das wichtig ist

Für Engineering-Teams, die KI-Infrastruktur aufbauen, verdeutlicht diese Schwachstelle die Risiken bei der Einführung neuer Beschleunigungstools ohne rigorose Sicherheitsaudits. LMCache ist darauf ausgelegt, die LLM-Inferenz zu beschleunigen, eine entscheidende Leistungsmetrik für Produktionsanwendungen. Allerdings ermutigen die vom Projekt bereitgestellten Standardbeispiele zu unsicheren Netzwerkbindungen. Betreiber, die diesen Beispielen folgen, um Multi-Node-Cluster einzurichten, setzen ihre Systeme unbeabsichtigt der Remote-Code-Ausführung aus.

Das Fehlen eines Patches zwingt Teams, sich zwischen Leistung und Sicherheit zu entscheiden. Das Deaktivieren der routbaren Adresse bricht das Multi-Node-Caching, was die Servicequalität beeinträchtigen kann. Offenhalten lässt die Tür weit für Angreifer offen. Diese Situation unterstreicht die Bedeutung von Defense-in-Depth-Strategien, wie strenge Netzwerksegmentierung und Least-Privilege-Prinzipien, anstatt sich ausschließlich auf die Anwendungssicherheit zu verlassen.

Darüber hinaus deutet die Entdeckung von sechs weiteren unbestätigten Sicherheitsberichten auf GitHub auf breitere Hygieneprobleme innerhalb des Projekts hin. Obwohl diesen keine CVEs oder Bestätigungen durch Maintainer vorliegen, weisen sie auf potenziellen nicht authentifizierten Zugriff auf Mandantendaten und andere Dienste hin. Teams, die LMCache nutzen, müssen nun nicht nur diese spezifische CVE überwachen, sondern auch die allgemeine Sicherheitslage des Projekts und dessen Reaktion auf neue Bedrohungen.

Was Sie tun können

• Netzwerkzugriff einschränken: Konfigurieren Sie den LMCache-Multiprozess-Server so, dass er nur auf localhost oder einem vertrauenswürdigen, isolierten Clusternetzwerk lauscht.

• Öffentliche Bindung vermeiden: Binden Sie den Server nicht an routbare Adressen, die von nicht vertrauenswürdigen Netzwerken oder dem öffentlichen Internet erreichbar sind.

• Firewalls implementieren: Verwenden Sie Firewall-Regeln, um strikt zu begrenzen, welche IP-Adressen sich mit dem LMCache-Port verbinden können, wobei zu beachten ist, dass dies das Risiko nicht vollständig mindert.

• Container-Berechtigungen prüfen: Ändern Sie, wenn möglich, die Container-Konfigurationen so, dass der LMCache-Prozess als Nicht-Root-Benutzer ausgeführt wird, um die Auswirkungen einer Ausnutzung zu begrenzen.

• Updates überwachen: Beobachten Sie das LMCache-Repository und JFrog-Advisories genau auf die Veröffentlichung einer gepatchten Version.

• Bereitstellungen auditieren: Überprüfen Sie bestehende Kubernetes- oder Docker-Bereitstellungen, um sicherzustellen, dass sie nicht die Standardbeispielkonfigurationen verwenden, die alle Schnittstellen exponieren.