LMCache-Sicherheitslücke: Laut JFrog kritisch bei Netzwerk-Bindung – so prüfen Sie Ihre vLLM-Cluster bis zum Fix

Ein ausgedachtes, aber nicht weit hergeholtes Szenario: Freitag, 17:15 Uhr, Shared-GPU-Cluster eines Teams, das namenlos bleiben darf. Für einen Multi-Node-Test hat jemand die Bindung von LMCache auf alle Interfaces gestellt, „nur bis Montag“. Die Nachbarknoten sollten endlich den Cache teilen, und vLLM lief ohnehin längst auf jedem Knoten.

Dann liest die Security-Verantwortliche das Advisory zur neuen Sicherheitslücke in LMCache. Kritisch, 9.8 laut JFrog, aber eben für die routbare Konfiguration. Sie schaut auf den Bildschirm, dann auf die Uhr. Hand aufs Herz: Wer von Ihnen hat einen Parameter nicht schon einmal „nur kurz“ geändert?

Dieser Text ist ein reiner Verteidiger-Ratgeber für alle, die LLM-Inferenz betreiben. Er klärt, wie ernst die Zahl wirklich ist, unter welcher Bedingung sie gilt und wie Sie auf Ihren eigenen Systemen herausfinden, ob Sie diese Bedingung erfüllen. Keine Angriffsbeschreibung, kein Drama. Prüfen, begrenzen, beobachten.

Was passiert ist: Eine Sicherheitslücke in LMCache mit Bedingung

Am Mittwoch, 7. Oktober, hat JFrog Security Research die Lücke veröffentlicht. Das Advisory trägt die Kennung JFSA-2026-001694382, entdeckt hat sie Yuval Moravchick von JFrog Security Research. Die zugehörige Kennung lautet CVE-2026-105192, nachlesen können Sie sie im offiziellen CVE-Record. Reserviert wurde sie am 4. Oktober, öffentlich ist sie seit dem 7. Oktober.

Das Pikante daran: JFrog ist zugleich die CNA. Das Unternehmen hat die CVE vergeben und die Lücke auch selbst bewertet. Die Bewertung ist also die Angabe des Forschungsteams, keine unabhängige Zweitprüfung. Das ist kein Vorwurf, sondern Kontext, den Sie kennen sollten, bevor Sie eine Zahl in ein Ticket schreiben.

Die Zahl lautet CVSS 3.1: 9.8, „kritisch“ laut JFrog. Sie gilt unter einer Bedingung. Das Szenario im CVE-Record ist der Multiprocess-Modus, gebunden an eine routbare Adresse, also die dokumentierte Multi-Node-Variante. JFrog schreibt dazu wörtlich: „The 9.8 score is for that routable configuration.“ Ohne diese Bedingung ist die Zahl nicht die ganze Geschichte.

Klassifiziert ist die Lücke als CWE-306 (fehlende Authentifizierung für eine kritische Funktion) und CWE-502 (Deserialisierung nicht vertrauenswürdiger Daten). In Worten: Der interne Transport des Multiprocess-Modus prüft nicht, wer sich verbindet, und verarbeitet Netzwerkdaten über eine unsichere Deserialisierung. Mehr Technik brauchen Sie als Betreibende nicht. Mehr Technik gibt es an dieser Stelle auch nicht.

Die Folge, nur als Kategorie: Wer den Transport-Port erreichen kann, kann laut JFrog Code mit den Rechten des LMCache-Prozesses ausführen. Laut JFrog laufen die offiziellen Container-Images diesen Prozess als root. Genau deshalb lohnt sich ein genauer Blick auf die Bindung.

Betroffen ist laut JFrog das Paket lmcache ab Version 0.3.9, einschließlich der aktuellen Release 0.5.5 und der Vorabversionen bis 0.5.6rc3, auch im Entwicklungszweig (Stand 7. Oktober). Der CVE-Record führt die Versionen ab 0.3.9 ohne Obergrenze. Vorsicht beim Kopffeld auf der JFrog-Seite: Dort steht „Affected versions = 0.3.9“. Das ist verkürzt und heißt nicht „nur 0.3.9“.

Und der Fix? JFrog meldete am 7. Oktober: „No fixed version has been published.“ Der CVE-Record vermerkt: „No fixed release is available as of 2026-10-07.“ Wir bei digital-magazin.de haben am Freitag, 9. Oktober, früh noch einmal nachgesehen. Neueste Release auf PyPI ist 0.5.5 vom 12. September, neueste Vorabversion 0.5.6rc3 vom 7. Oktober, danach gibt es nur Nightly-Builds. Release-Notes oder ein Security-Advisory von LMCache mit Bezug zur Lücke haben wir nicht gefunden.

Stand 9. Oktober ist also keine korrigierte Version veröffentlicht. Ob Nightly-Builds bereits etwas ändern, ist nicht dokumentiert. Für den Produktivbetrieb zählt ein Release, und das sehen Sie auf der Releases-Seite von LMCache.

Was LMCache macht – und warum vLLM-Betreibende hinsehen sollten

Ein kurzer Ausflug für alle, die LMCache bisher nur vom Hörensagen kennen. Große Sprachmodelle legen beim Verarbeiten einer Eingabe einen Zwischenspeicher an, den KV-Cache: die Schlüssel und Werte der Attention-Schichten. Geht dieser Speicher verloren oder liegt er auf dem falschen Rechner, muss das Modell Arbeit wiederholen.

LMCache ist ein Open-Source-Projekt, das genau diesen KV-Cache über Prozesse und Rechner hinweg teilt und wiederverwendet. Eingesetzt wird es unter anderem zusammen mit vLLM. Leistungszahlen nenne ich bewusst nicht, sie spielen für die Sicherheitsfrage keine Rolle. Wer die Infrastruktur dahinter einordnen möchte, findet in unserem Text zur Inferenz-Infrastruktur den nötigen Kontext.

Für die Lücke zählt ein einziger Punkt: der Modus. Betroffen ist nur der Multiprocess-Modus, der auch „distributed mode“ heißt. Dort kommunizieren mehrere Prozesse über einen eigenen Transport miteinander, und genau dieser Transport ist der Kern der Sicherheitslücke.

Die wichtigste Entwarnung steht direkt bei JFrog, und ich zitiere sie, weil sie vielen Betreibenden den Abend retten dürfte: „LMCache used only inside a vLLM process does not open this port.“ Läuft LMCache ausschließlich innerhalb des vLLM-Prozesses, öffnet es laut JFrog diesen Port gar nicht.

Beachten Sie: Das ist eine Angabe von JFrog. Prüfen Sie sie an Ihrer eigenen Installation, statt sie zu glauben. Wie das geht, folgt gleich.

Eine kritische Wertung mit Bedingung: Die Sicherheitslücke steckt im Code, das Risiko in der Konfiguration

Schauen wir die Bedingung genauer an. Der Transport bindet standardmäßig an localhost. Nur wenn Betreibende mit dem Parameter –host eine routbare Adresse setzen, also die dokumentierte Multi-Node-Variante wählen, ist er von anderen Rechnern erreichbar. JFrog formuliert es so: „A stock single-host install that leaves the default bind is not reachable from other machines.“

Übersetzt: Die 9.8 laut JFrog beschreibt die routbare Konfiguration. Spoiler: Eine Standardinstallation auf einem einzelnen Host mit unveränderter Bindung ist laut JFrog von anderen Maschinen aus nicht erreichbar. Das ersetzt keine Prüfung, aber es sortiert die Dringlichkeit.

Plot Twist: Genau die Multi-Node-Setups, die LMCache überhaupt interessant machen, sind die, in denen jemand die Bindung öffnet. Wer den Cache zwischen Rechnern teilen will, muss den Transport erreichbar machen. Das ist kein Konfigurationsfehler, das ist der Zweck.

Mein Befund lautet daher: Die Lücke steckt im Code, das Risiko entsteht in der Konfiguration. Ohne routbare Bindung bleibt die Fehlstelle im Transport, aber sie liegt hinter einer Tür, die laut JFrog von anderen Rechnern aus nicht erreichbar ist. Mit routbarer Bindung hängt alles daran, wer diese Tür erreichen darf.

Ich finde, das ist die ehrlichste Lesart der Zahl. Sie ist weder harmlos noch ein Grund zum Aktionismus auf jedem Rechner. Sie ist ein Auftrag an alle, die im Cluster Bindungen setzen: Wissen Sie, welche Ihrer Knoten den Transport nach außen anbieten?

Das ist der Knackpunkt. Nicht „bin ich auf 0.5.5?“, sondern „wer erreicht den Transport?“. Die Version sagt Ihnen nur, ob die Fehlstelle im Code existiert. Die Antwort auf die zweite Frage entscheidet, ob daraus ein Problem wird.

Überraschung: Das ist eine gute Nachricht. Konfiguration lässt sich prüfen und ändern, ohne auf ein Release zu warten. Auf einen Patch hingegen kann niemand von außen Einfluss nehmen.

Bin ich betroffen? Prüffragen zur Sicherheitslücke in Ihrer Konfiguration

Die folgenden Fragen beantworten Sie ausschließlich auf Ihren eigenen Systemen. Sie brauchen dafür keinen Scanner und keine fremden Werkzeuge, nur Zugriff auf Ihre Hosts, Repositories und Cluster-Konfigurationen.

• Welche Version läuft? Prüfen Sie auf Ihren Hosts mit pip show lmcache oder lesen Sie bei Containern den Image-Tag. Laut JFrog zählt jede Version ab 0.3.9, einschließlich 0.5.5 und der Vorabversionen bis 0.5.6rc3.
• Läuft LMCache im Multiprocess-Modus (auch „distributed mode“) oder ausschließlich innerhalb des vLLM-Prozesses? Nur der erste Fall betrifft die Lücke, im zweiten öffnet LMCache laut JFrog diesen Port nicht.
• Taucht –host in Startskripten, Compose-Dateien, Helm-Charts, Kubernetes-Manifesten oder Infrastructure-as-Code auf, und mit welchem Wert? Durchsuchen Sie dafür Ihre eigenen Repositories und Konfigurationsdateien, auch die alten Branches und die Testumgebungen.
• Auf welcher Adresse lauscht der Dienst tatsächlich? Fragen Sie auf dem jeweiligen eigenen Host lokal mit ss -ltn ab, ob der Transport an localhost oder an eine andere Adresse gebunden ist. Was die Konfiguration verspricht und was der Host tut, sind zwei verschiedene Dinge.
• Wer kann den Transport im Netz überhaupt erreichen? Gehen Sie Firewall-Regeln, Security Groups und NetworkPolicies durch und notieren Sie, ob der Kreis auf Cluster-Knoten begrenzt ist oder weiter reicht.
• Als welcher Benutzer läuft der Prozess? Laut JFrog laufen die offiziellen Container-Images den LMCache-Prozess als root. Haben Sie das in Ihrem Setup geändert, oder erbt Ihr Deployment den Standard?
• Wer darf Bindungen im Cluster ändern, und gibt es dafür ein Review? Ein Parameter, den eine Person allein am Freitagnachmittag ändern kann, ist ein Prozessrisiko.

Werten Sie die Antworten in Schichten aus. Läuft kein Multiprocess-Modus, ist die Bedingung laut JFrog nicht erfüllt. Läuft er an localhost, ist der Transport laut JFrog von anderen Rechnern aus nicht erreichbar. Läuft er an einer routbaren Adresse, beginnt die eigentliche Arbeit: Kreis der Erreichenden bestimmen, Folgen begrenzen, Fix beobachten.

Eine Sache gehört noch dazu, und sie wird gern vergessen. Prüfen Sie nicht nur die Produktion. Gerade Test-, Staging- und Experimentierumgebungen bekommen die Bindung, die „nur kurz“ gebraucht wird, und verbleiben dann Wochen im Netz. Das geht mir regelmäßig auf die Nerven, weil es so vermeidbar ist.

Halten Sie das Ergebnis schriftlich fest, auch wenn es „nicht betroffen“ lautet. Ein Satz im Ticket, welche Version, welcher Modus, welche Bindung, spart Ihnen beim nächsten Advisory die halbe Recherche. Und es beantwortet die Frage der Geschäftsleitung, bevor sie gestellt wird.

Was JFrog empfiehlt – eine Quelle, drei Maßnahmen

Bis ein Release die Korrektur enthält, empfiehlt JFrog drei Dinge. Ich gebe sie wortlaut-nah wieder und kennzeichne sie als das, was sie sind: Empfehlungen des Forschungsteams, nicht meine.

Erstens: „Until a release includes that change, do not set –host to a routable address.“ Also: Bis ein Release die Korrektur enthält, setzen Sie –host nicht auf eine routbare Adresse. Wer es noch nicht getan hat, lässt es.

Zweitens: „Keep the multiprocess port on localhost or on a trusted cluster network.“ Der Port des Multiprocess-Modus bleibt demnach auf localhost oder in einem vertrauenswürdigen Cluster-Netz. Das Wort „vertrauenswürdig“ trägt hier die ganze Last, und es gehört in Ihr eigenes Netzkonzept, nicht in eine Wunschvorstellung.

Drittens zur Firewall: „Limiting the port with a firewall reduces who can reach it.“ Praktisch heißt das eine Regel, die den Standardport des Transports, 5555, nur für Cluster-Knoten öffnet. Der zweite Satz bei JFrog folgt unmittelbar und ist mindestens so wichtig. Dazu im nächsten Abschnitt mehr.

Für Ihre Umsetzung folgt daraus eine Rangfolge. Am besten ist es, wenn die routbare Bindung gar nicht erst existiert. Ist sie für den Multi-Node-Betrieb unverzichtbar, dann auf ein vertrauenswürdiges Cluster-Netz begrenzen. Die Firewall kommt als zusätzliche Verkleinerung des Kreises obendrauf, nicht als Ersatz.

Und wenn der Multi-Node-Betrieb gerade nur ein Test war? Dann ist die Antwort banal: Bindung zurück auf localhost, Test später mit sauberem Netzkonzept wiederholen. Ein Experiment rechtfertigt kein dauerhaft offenes Tor.

Warum die Firewall kein Patch ist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of two IT security colleagues at a desk on a Friday evening reviewing a checklist on paper with blank lines, monitors in front of them show only blurred abstract network diagrams, office lights on, faces not visible, no logos, no brand marks, no readable text, no letters, no watermarks, 16:9

JFrog formuliert die Grenze der Firewall-Maßnahme selbst, und zwar unmissverständlich:

„Limiting the port with a firewall reduces who can reach it. Any host that can open a connection to the port can still run code as the LMCache user.“

JFrog Security Research, Advisory zu CVE-2026-105192

Die Firewall verkleinert also den Kreis derer, die den Port erreichen. Sie beseitigt die Lücke nicht, und sie ersetzt den Fix nicht. Jeder Host, der innerhalb des erlaubten Kreises eine Verbindung aufbauen kann, kann laut JFrog weiterhin Code mit den Rechten des LMCache-Nutzers ausführen.

Stellen Sie sich einen Türsteher vor, der nur weiß, wer nicht rein darf. Er hält draußen, wer auf seiner Liste steht. Wer dort nicht auftaucht, geht durch. Und drinnen fragt niemand mehr nach.

Das ist die Lage im Transport: Er prüft nicht, wer sich verbindet. Die Firewall ist also die einzige Prüfung, die noch stattfindet, und sie prüft nur die Netzadresse. Wir haben ein ähnliches Muster schon bei einem früheren Fall beschrieben, in dem eine Zugriffsliste bis zum Patch nur die Brücke war. Brücken sind nützlich, aber niemand wohnt auf ihnen.

Wer die Lücke wirklich schließen kann, sind die Maintainer. JFrog empfiehlt ihnen, keine Netzwerkdaten unsicher zu deserialisieren, den Transport zu authentifizieren und eine routbare Bindung ohne Authentifizierung zu verweigern. Das ist eine Fix-Empfehlung an das Projekt, keine Betreiber-Maßnahme. Sie können das nicht selbst konfigurieren.

Für Betreibende folgt daraus ein klarer, wenn auch unbequemer Punkt: Aktivieren Sie die Authentifizierung, sobald ein Release sie anbietet. Bis dahin gilt, dass der Schutz in Netz und Prozess liegen muss, nicht im Transport selbst. Das ist unbefriedigend. Es ist aber der Stand.

Meiner Einschätzung nach ist das die eigentliche Lehre: Ein Transport, der nur im vertrauenswürdigen Netz sicher ist, braucht ein Netz, dessen Vertrauenswürdigkeit jemand regelmäßig prüft. Wer das nicht kann, sollte die routbare Bindung gar nicht erst anbieten.

Root im Container: Folgen begrenzen, Lücke bleibt

Jetzt zu meinen eigenen Ergänzungen. Mein Rat, nicht JFrogs: Lassen Sie den Prozess nicht als root laufen. JFrog stellt lediglich fest, dass die offiziellen Container-Images den Prozess als root starten. Alles, was nun folgt, ist meine Einordnung, nicht die des Forschungsteams.

Ein eigener Nicht-root-Benutzer, möglichst wenige Capabilities und ein schreibgeschütztes Dateisystem, wo es geht. Das begrenzt die Folgen, wenn jemand Code mit den Rechten des Prozesses ausführt. Es verhindert die Lücke nicht. Das muss ich so deutlich sagen, weil „Non-root“ gern als Heilmittel missverstanden wird.

Der Gedanke dahinter ist Least Privilege, und er hat in der KI-Infrastruktur schon andere Anwendungsfälle gefunden. Was wir dazu über Isolation und Sandboxen geschrieben haben, passt hier fast eins zu eins: Was ein Prozess nicht darf, kann auch eine Fehlstelle nicht erzwingen.

Dazu kommt die Netzsegmentierung. Das GPU- und Inferenz-Knotennetz gehört getrennt vom Büro- und Nutzernetz. Wer vom Notebook im Großraumbüro aus den Transport eines Inferenz-Knotens erreicht, hat ein Netzdesignproblem, ganz unabhängig von dieser Lücke. Die Lücke macht es nur sichtbar.

Dritter Punkt: Änderungen an Bindungen im Cluster nur per Review oder Change-Prozess. Zwei Augenpaare vor einer Änderung an –host kosten Minuten. Eine vergessene Änderung kann Wochen im Netz stehen. Ehrlich gesagt gehört das zu den günstigsten Maßnahmen in diesem Text.

Vierter Punkt: Beobachten Sie die Releases-Seite und den CVE-Record, und aktualisieren Sie zeitnah, sobald ein Fix-Release erscheint. Legen Sie dafür ein Ticket mit Verantwortlichen an, nicht nur ein gutes Gefühl. Für den Fall, dass eine routbare Bindung längere Zeit offen war, bewerten Sie das mit Ihrem eigenen Incident-Prozess. Das ist eine Frage der Einordnung, kein Urteil.

Zurück zum Freitag, 17:15 Uhr

Kehren wir zum ausgedachten Cluster zurück. Die Security-Verantwortliche öffnet nicht den Notfallkanal, sondern die Repositories. Sie sucht nach –host und findet die Bindung auf alle Interfaces im Manifest des Testknotens. Sie steht dort, wie angekündigt, „nur bis Montag“.

Der Multi-Node-Test läuft weiter, aber anders. Die Bindung wird auf das vertrauenswürdige Cluster-Netz begrenzt, und wo der Test es nicht braucht, geht sie zurück auf localhost. Die Änderung läuft über den Review, auch am Freitagabend. Es dauert zehn Minuten, und das Team lebt damit.

Danach folgt die Firewall-Regel, die den Transport nur für Cluster-Knoten erreichbar macht. Sie verkleinert den Kreis, mehr nicht. Das schreibt die Verantwortliche auch ins Ticket, damit niemand am Montag denkt, damit sei die Sache erledigt.

Dann prüft sie den Container-User. Läuft der Prozess als root, wird das als Aufgabe mit Frist eingetragen: eigener Nicht-root-Benutzer, nur nötige Capabilities. Auch das begrenzt die Folgen, es verhindert nichts, und auch das steht im Ticket.

Zuletzt legt sie ein Ticket an: „Fix-Release beobachten“. Mit Verantwortlichen, mit Prüfintervall auf Releases-Seite und CVE-Record, mit der Aufgabe, nach einem Fix zeitnah zu aktualisieren und Authentifizierung zu aktivieren, sobald sie angeboten wird. War die Bindung zuvor länger offen, geht eine Notiz an den Incident-Prozess zur Bewertung.

Um 18:40 Uhr ist Feierabend. Nichts ist passiert, und genau so soll es aussehen. Es gab keinen Schaden und keinen Angriff, nur eine Konfiguration, die jetzt dem entspricht, was das Netzkonzept ohnehin versprochen hat.

Lokal hosten: Die Lücke betrifft nicht jede Heimanlage

Ein Wort an alle, die zu Hause oder im kleinen Büro Modelle lokal hosten. Wer das auf einem einzelnen Rechner tut, betreibt meist ein Single-Host-Setup. Laut JFrog ist eine Standardinstallation mit unveränderter Bindung von anderen Rechnern nicht erreichbar. Und wer LMCache nur innerhalb des vLLM-Prozesses nutzt, öffnet diesen Port laut JFrog gar nicht.

Das gilt aber nur, solange die Bindung Default bleibt. Stellen Sie nichts „mal eben“ auf alle Interfaces, weil eine Anleitung es vorschlägt oder weil der Zugriff vom Laptop bequemer wäre. Wie Sie lokale KI im Heimnetz sauber absichern, haben wir in unserem Ratgeber zum Härten lokaler KI im Heimnetz beschrieben. Das Prinzip ist dasselbe wie im Rechenzentrum, nur kleiner.

Was noch fehlt

Offen ist vor allem eines: das Fix-Release. Wann es kommt, ist unbekannt, und Stand 9. Oktober hat LMCache weder Release-Notes noch ein Security-Advisory zur Lücke veröffentlicht. Auch die Authentifizierung im Transport steht noch aus. Zahlen zu erreichbaren Installationen nennen die Quellen nicht.

Wir bei digital-magazin.de beobachten die Releases weiter und ergänzen, was sich belegen lässt. Bis dahin bleibt Ihnen, was Sie selbst in der Hand haben: Bindung prüfen, Kreis begrenzen, Folgen eindämmen, Releases im Blick behalten.

Der Punkt ist: Eine 9.8 laut JFrog für die routbare Konfiguration ist ernst zu nehmen, aber sie ist keine Aussage über Ihren Cluster. Ihren Cluster kennen nur Sie. Sehen Sie nach.