Am 7. Oktober 2026 veröffentlichte JFrog eine kritische Schwachstelle in LMCache, einer Open-Source-Software, die LLM-Server wie vLLM beschleunigt. Die Schwachstelle CVE-2026-105192 erreicht eine CVSS-Bewertung von 9,8, wenn der Mehrprozess-Server an eine routbare Adresse gebunden ist. Bisher ist noch keine gepatchte Version verfügbar.
Ein unauthentifizierter Angreifer, der auf den ZeroMQ-Port zugreifen kann, kann Code als Benutzer des LMCache-Prozesses ausführen – oft als root in offiziellen Container-Bildern.
Im Mehrprozess-Modus läuft LMCache als eigenständiger Cache-Server, den LLM-Arbeiter über ZeroMQ erreichen. Standardmäßig hört er nur auf localhost. Er wird für andere Hosts erreichbar, wenn Betreiber eine routbare Adresse festlegen – ein häufiger Fall in mehrknotigen Clustern. Das eigene Kubernetes-Beispiel des Projekts startet den Server so, dass er auf allen Schnittstellen zuhört. LMCache innerhalb eines einzelnen vLLM-Prozesses öffnet den Port gar nicht.
Der ZeroMQ-Socket verfügt über keine Authentifizierung. Eine Nachrichtentypen wird mit dem Python-Modul `pickle` entpackt, das Code ausführen kann, sobald es decodiert wird. Der Server entpackt die Argumente beim Lesen, bevor er den Nachrichtentyp prüft, wodurch ein manipulierter Nachrichteninhalt den Code des Senders sofort ausführt. Betroffene Versionen: 0.3.9 (Oktober 2025) bis 0.5.5 (aktuell stabil), inklusive der Release-Candidates von 0.5.6 sowie der Entwicklungszweig. Entdecker: Yuval Moravchick, JFrog Security Research.
Bis ein Patch verfügbar ist, empfiehlt JFrog, dem Multiprocess-Server keine routbare Adresse zuzuweisen und den Port auf der lokalen Maschine oder einem vertrauenswürdigen Cluster-Netzwerk zu belassen. Ein Firewall reduziert zwar das Risiko, beseitigt es jedoch nicht – jeder Host, der sich noch verbinden kann, kann Code ausführen. LMCache hat keine eigene Sicherheitswarnung veröffentlicht, und JFrog bietet keine Möglichkeit, festzustellen, ob ein Server bereits angegriffen wurde.
Am Tag vor der Veröffentlichung der CVE wurden sechs zusätzliche GitHub-Berichte veröffentlicht, die unbefugten Zugriff auf den Cache und Netzwerkdienste mehrerer Mieter ohne Anmeldung melden – ohne CVE, ohne Bestätigung durch den Betreiber. Ein verwandtes DoS-Risiko in vLLM (CVE-2026-105756, CVSS 6.5) im LMCache-Multiprocess-Connector ist bereits in der Version vLLM 0.30.0 behoben. Das Muster – unbefugter Socket-Zugriff auf pickle – erinnert an die ShadowMQ-Ergebnisse in AI-Inferenz-Frameworks aus November 2025.
Für Organisationen, die AI-Agenten und LLM-Infrastruktur in der Produktion betreiben, stellt sich hier eine dringende Sicherheitsfrage: Ein versehentlich auf 0.0.0.0 gebundener Cache-Server wird zu einer ungesicherten RCE-Oberfläche. Inventarisieren Sie alle vLLM/LMCache-Deployments, entfernen Sie routbare Bindungen und segmentieren Sie die Cluster-Netzwerke.
LLM-Cache-Stufen werden oft in der Vulnerability-Management-Strategie vernachlässigt, weil sie als „interne Leistungsbestandteile“ behandelt werden – nicht als Angriffsfläche. In der Praxis stehen sie neben GPU-Knoten, laufen häufig als Root in Containern und können Zugriff auf Modelle, Prompts und manchmal auch Geheimnisse haben, die über Umgebungsvariablen injiziert werden. Ein Pickle-RCE dort ist nicht nur ein DoS – es kann zu Diebstahl von Modellgewichten, Prompt-Injection gegen andere Worker und einem Einbruch in den Cluster führen. Die Lehren aus ShadowMQ 2025 bleiben gültig: Serialisierungsformate, die Code ausführen, gehören nicht hinter unauthentifizierte Sockets.
Nordische KI-Labore, SaaS-Unternehmen und öffentliche Pilotprojekte, die vLLM testen, sollten besonders Helm-Charts und Terraform-Module prüfen, die das LMCache-Beispiel für Kubernetes kopiert haben. Ein Default-Listen auf allen Schnittstellen ist zwar im Labor praktisch, aber in der Produktion gefährlich. Setzen Sie ZeroMQ hinter NetworkPolicy, mTLS oder zumindest `hostNetwork=false` mit einem strikten Pod-CIDR. Dokumentieren Sie, welches Team für den Cache-Knoten verantwortlich ist – sonst wird das Patching bei Warnungen schnell zum „Problem von jemand anderem“, wenn die Meldungen endlich eintreffen.
**Was IT- und Sicherheitsverantwortliche jetzt tun sollten**
Lagervorrat LMCache 0.3.9–0.5.5 (und RCs). Falls der Mehrprozessmodus verwendet wird: stellen Sie sicher, dass ZeroMQ nur auf localhost oder privaten Cluster-Netzen hört; entfernen Sie bindbare Routing-Bindungen. Aktualisieren Sie vLLM auf ≥0.30.0 für die CVE-2026-105756. Überwachen Sie unerwartete Prozesse/Verbindungen von LMCache-Containern. Planen Sie die Anwendung des Hersteller-Patches, sobald er verfügbar ist – bis dahin ist Netzwerkisolation die einzige wirksame Kontrolle. Überprüfen Sie außerdem, ob pickle in anderen internen KI-Diensten verwendet wird, und ersetzen Sie es wo möglich durch sicherere Protokolle.