Wer große Sprachmodelle selbst betreibt, tut das meist aus einem Grund: Kontrolle über die eigenen Daten. Ausgerechnet dort klafft jetzt eine kritische Sicherheitslücke. Das Security-Research-Team von JFrog hat am 7. Oktober 2026 eine Schwachstelle in LMCache öffentlich gemacht, einer weit verbreiteten Cache-Schicht für die Inferenz-Engine vLLM. Die Lücke trägt die Kennung CVE-2026-105192, ist mit einem CVSS-Wert von 9,8 als kritisch eingestuft – und zum Zeitpunkt der Veröffentlichung existierte kein Patch.
Eine einzige Nachricht genügt
LMCache ist eine verteilte Key-Value-Cache-Schicht, die Zwischenergebnisse der Inferenz speichert und so die Antwortzeiten von vLLM-Deployments deutlich verkürzt. Das Projekt gehört zur PyTorch Foundation, zählt über 9.200 GitHub-Sterne und ist Teil des offiziellen vLLM-Produktionsstacks.
Das Problem: Im Multiprocess-Modus öffnet LMCache einen ZeroMQ-ROUTER-Socket auf Port 5555 – ohne Authentifizierung und ohne Verschlüsselung. Eingehende Nachrichten werden per msgpack dekodiert, und beim Erweiterungscode 1 ruft die Software direkt pickle.loads() auf die unkontrollierten Daten auf. Da Pythons Pickle-Format beim Deserialisieren beliebigen Code ausführen kann, bedeutet das: Eine einzige präparierte Netzwerknachricht an Port 5555 reicht, um eigenen Code auf dem Server auszuführen. Entdecker Yuval Moravchick bringt es auf den Punkt: „The server unpacks messages before validating their type" – der Server entpackt Nachrichten, bevor er ihren Typ überhaupt prüft. Besonders brisant: Die offiziellen Container-Images betreiben LMCache als Root, ein erfolgreicher Angriff liefert also volle Kontrolle über den Container. Ein öffentlicher Proof-of-Concept kursiert bereits.
Wer betroffen ist – und wer nicht
Verwundbar sind die LMCache-Versionen 0.3.9 bis einschließlich 0.5.5 sowie die Vorabversionen bis 0.5.6rc3. Die Software steckt unter anderem in Google Cloud GKE Inference, bei CoreWeave, in NVIDIA Dynamo und in IBMs LLM-Serving-Stack. Aus der Ferne ausnutzbar sind vor allem Multi-Node- und Kubernetes-Deployments, bei denen der Dienst an eine von außen erreichbare Adresse gebunden ist – genau diese Konfiguration empfiehlt die offizielle Dokumentation allerdings für Produktionsumgebungen. Wichtig zur Einordnung:
- Single-Node-Setups, die nur an localhost (127.0.0.1) gebunden sind, sind aus der Ferne nicht angreifbar.
- Desktop-Lösungen wie Ollama oder LM Studio setzen LMCache nicht ein und sind von dieser Lücke nicht betroffen.
- JFrog empfiehlt, Port 5555 per Firewall beziehungsweise Kubernetes NetworkPolicy zu blockieren, die Host-Bindung auf 127.0.0.1 zu beschränken und den ZeroMQ-Transport per CURVE oder HMAC abzusichern.
Beunruhigend ist zudem: Bereits am 6. Oktober, einen Tag vor der Veröffentlichung, wurden sechs weitere Sicherheitsmeldungen zu LMCache eingereicht, die bislang weder bestätigt noch mit CVE-Nummern versehen sind.
Was bedeutet das für Anwender in Deutschland?
Die Lücke trifft einen wunden Punkt: Viele deutsche Unternehmen hosten Sprachmodelle gerade deshalb selbst, weil sie ihre Daten DSGVO-konform im eigenen Haus halten wollen – und vLLM ist dafür der De-facto-Standard. Die Ironie: Ausgerechnet die On-Premise-Infrastruktur, die den Datenabfluss verhindern soll, kann bei offenem Port 5555 per Root-Zugriff komplett übernommen werden. Gelangen dabei personenbezogene Daten in fremde Hände, greift die Meldepflicht nach Artikel 33 DSGVO – binnen 72 Stunden an die zuständige Aufsichtsbehörde. Für Betreiber, die unter die NIS2-Umsetzung fallen, kommen weitere Melde- und Härtungspflichten hinzu.
Konkret sollten IT-Verantwortliche im Mittelstand jetzt drei Dinge tun: Erstens prüfen, ob in der eigenen vLLM-Umgebung LMCache aktiv ist – etwa in Kubernetes-Clustern oder Multi-GPU-Setups. Zweitens Port 5555 sofort per Firewall und NetworkPolicy abschotten, auch im internen Netz, denn ein kompromittierter Client genügt für den Angriff. Drittens die LMCache-Releases beobachten und den Patch einspielen, sobald er erscheint. Wer lokale Modelle nur auf einem Einzelrechner mit Ollama oder LM Studio betreibt, kann dagegen entspannt bleiben. Einen Überblick über Schutzwerkzeuge bietet unsere Kategorie KI-Sicherheit, Grundlagen erklärt der Glossar-Eintrag zur Inferenz.