LMCache CVE-2026-105192: Ausführung vor Ablehnung

Die Anfrage scheiterte. Der Code war bereits ausgeführt.

Die Anfrage scheiterte. Der Code war bereits ausgeführt. Genau diese Reihenfolge ist das Problem in LMCache CVE-2026-105192: Ein unsicherer Deserialisierer arbeitet bereits beim Dekodieren der Argumente, bevor der fachliche Handler sie ablehnen kann. Eine Fehlerantwort kommt zu spät, um die Harmlosigkeit der Anfrage zu belegen.

Das Advisory umfasst LMCache 0.3.9 bis 0.5.5, betroffene Vorabversionen von 0.5.6 sowie Entwicklungsstände vor dem Fix. Version 0.5.6 enthält die Reparatur. Dies ist eine Quellcode- und Patchanalyse, keine Reproduktion; besonders bei den folgenden Negativtests ist diese Unterscheidung wichtig. Betroffen ist erreichbarer verwundbarer Multiprocess-Transport, nicht jede Anwendung mit vLLM. [1][2]

Wie erreicht die MessagePack-Dekodierung pickle?

Der Transport nimmt MessagePack entgegen, doch sein eigener Extension-Hook interpretiert bestimmte Bytes ein zweites Mal. Extension-Code 1 erreicht DeviceIPCWrapper.Deserialize, dessen verwundbare Implementierung pickle.loads aufruft. Im REGISTER_KV_CACHE-Pfad geschieht das noch beim Aufbau der Handler-Argumente. Eine anschließende Argumentprüfung kann bereits eingetretene Seiteneffekte nicht rückgängig machen. [1][3]

So würde ich die Grenze im Review verfolgen: beim Netzwerkdecoder beginnen, Hooks und eigene Konverter erfassen und jedem Pfad folgen, bis aus Bytes entweder gewöhnliche Daten oder eine ausführbare Objektrekonstruktion werden. Der Formatname im Architekturdiagramm genügt nicht. Ein datenorientiertes äußeres Format kann eine Erweiterung enthalten, die das gefährliche Verhalten wieder einführt, das die äußere Schicht scheinbar vermeidet.

Affected decode path (schematic)

Peer-controlled frame
  -> MessagePack argument decode
  -> extension code 1
  -> DeviceIPCWrapper.Deserialize
  -> pickle.loads
  -> only then: handler / later validation

A later error cannot undo an earlier side effect.

Der Entwickler brauchte die richtige Unterklasse zurück

Der verwundbare Code beschreibt sein Entwicklungsziel: Der konkrete Typ des Geräte-Wrappers soll die Übertragung überstehen, damit der Empfänger die richtige Implementierung zur Tensor-Konvertierung auswählt. CPU- und Beschleuniger-Wrapper erfüllen unterschiedliche Aufgaben. Objektserialisierung löste diese Auswahl bequem, erlaubte einem Peer aber zugleich, Bytes an die Python-Objektrekonstruktion zu liefern. Der Sicherheitsfehler liegt in der Darstellung einer legitimen Anforderung. [3]

Die nützlichere Review-Frage lautet deshalb: Welche Fakten müssen die Grenze überschreiten, und welche Implementierungsentscheidungen müssen lokal bleiben? Ein Empfänger benötigt möglicherweise Geräteart, Form oder Speicherdeskriptor. Eine beliebige Anleitung zum Konstruieren von Python-Objekten benötigt er nicht. Diese Trennung gibt dem Patch eine Invariante, die auch bei einem Transportwechsel bestehen bleibt.

Der Patch verlagert die Implementierungsauswahl zurück in lokalen Code

In 0.5.6 dekodiert Deserialize einen typisierten WireIPCData-Deskriptor und wählt anhand dessen Typ einen Eintrag aus WRAPPER_TYPES. Modul und Klasse stammen aus dieser lokalen Zuordnung. Dass importlib im reparierten Pfad steht, ist allein kein neuer Injection-Befund: Entscheidend ist, ob die Eingabe den importierten Namen bestimmt oder lediglich einen ausdrücklich unterstützten Deskriptor auswählt. [4]

Der Patch behält die Serialisierungsschnittstelle bei, lehnt alte Pickle-Daten jedoch ab. Mein Abnahmekriterium lautet: Ungültige oder nicht unterstützte Wire-Daten scheitern vor beliebiger Objektrekonstruktion, ohne Kompatibilitätszweig, der still auf pickle zurückfällt. Ich würde unbekannte Tags, unerwartete Felder und alte Deskriptoren neben gültigen Eingaben testen. Ein Sicherheitsfix muss beabsichtigte Funktionen erhalten und die gefährliche Interpretation entfernen.

# Selected source lines; surrounding checks omitted [3][4]
# Vulnerable:
return pickle.loads(data)

# Fixed:
descriptor = msgspec.msgpack.decode(data, type=WireIPCData)
module, name = WRAPPER_TYPES[type(descriptor)]

# The fixed path selects implementation from a local mapping.

Verfolgen Sie den gemeinsamen Decoder über den ersten Socket hinaus

ZeroMQ ist nicht der einzige relevante Aufrufer. Der Fix-PR nennt einen gRPC-Codec, der denselben Deserialisierer über ein Feld namens pickled_payload nutzt. Dieser Feldname bleibt aus Kompatibilitätsgründen bestehen, obwohl sein Inhalt zum neuen Deskriptor wird. Eine Suche nach dem alten Namen kann Gefahr überbewerten; eine Suche ausschließlich im ersten Transport kann die gemeinsame Grenze übersehen. Folgen Sie dem tatsächlichen Datenfluss. [5]

Der Fix entfernt auch nicht sämtliche Pickle-Nutzung aus LMCache. Die Maintainer benennen separate Engine-driven-Pfade außerhalb dieser Reparatur und beschreiben sie in der Standardkonfiguration als deaktiviert und nicht netzwerkerreichbar. Das ist ihre Aussage zum Umfang, kein hier nachgewiesenes Erreichbarkeitsergebnis. Der Patch schafft weder RPC-Authentifizierung noch eine Autorisierung für referenzierte Shared-Memory-Ressourcen. Syntax, Identität und Ressourcenbesitz sind getrennte Prüfungen. [5][6]

Ein gültiger Deskriptor belegt keine Ressourcenberechtigung

Das Ersatzschema ändert mehr als die Serialisierungsbibliothek. TensorMetadata beschränkt numerische Felder und prüft die übereinstimmende Rangzahl von shape und stride. Der CPU-Shared-Memory-Deskriptor prüft, ob die beschriebene Tensoransicht in die angegebene Größe passt. Damit wird die Bedeutung eines Deskriptors begrenzt, bevor ein Wrapper ihn nutzt. Ein Reviewer kann daraus konkrete Grenzfälle ableiten, statt das Wort typisiert als Sicherheitsgarantie zu akzeptieren. [7]

Eine andere Frage bleibt: Wer darf die zugrunde liegende Ressource benennen oder verwenden? Eine intern konsistente Beschreibung beantwortet das allein nicht. Der PR trennt Deskriptorvalidierung ausdrücklich von Shared-Memory-Eigentumsautorisierung. Ich würde die Ressourcenberechtigungsprüfung samt Position getrennt von der Dekodierungsprüfung dokumentieren und, soweit das Vertrauensmodell es verlangt, für beide Belege fordern. Das behauptet keine neue Schwachstelle der reparierten Version, sondern begrenzt die Aussage des Patches. Dieselbe Disziplin gilt für jeden Parser-Fix: Benennen Sie die nun erzwungene Invariante und anschließend die unabhängigen Sicherheitsentscheidungen, die der Patch nie zugesagt hat. Ein bestandener Parser-Test zertifiziert diese Entscheidungen nicht nebenbei. [5]

Ein fehlender Marker braucht einen Nachweis abgeschlossener Verarbeitung

Ein Test kann einen Fehlschlag melden, bevor der verwundbare Server seine Eingabe verarbeitet hat. Der PR-Autor behandelt dieses asynchrone Timingproblem ausdrücklich: Eine Folgeanfrage auf derselben Verbindung bestätigt den Abschluss, bevor der Marker geprüft wird. Das veröffentlichte Vorher-Nachher-Ergebnis stammt von diesem Autor, nicht aus meinem Labor. Die allgemeine Lehre: Belegen Sie, dass die Prüfung nach der relevanten Verarbeitung stattgefunden hat. [5]

Von einer lokalen Regressionstestumgebung würde ich vier Beobachtungen verlangen: Die Anfrage erreichte den vorgesehenen Decoder, die Verarbeitung endete, der verbotene Seiteneffekt blieb aus und eine gültige Anfrage funktionierte weiterhin. Ein Timeout ersetzt keine Ablehnung. Eine Exception ersetzt auch keine Beobachtung von Seiteneffekten: Der verwundbare Pfad kann erst nach der Ausführung scheitern. Binden Sie jede negative Aussage an den belegten Codepfad und seine Abschlussbedingung.

Proposed regression evidence; not results from a run here

Affected build: path reached + completed + benign marker observed
Fixed build:    path reached + completed + marker absent
Valid input:   supported round trip still works
No completion: inconclusive, even when the marker is absent

Aktualisieren Sie die Teilnehmer und prüfen Sie ihre Erreichbarkeit

Beginnen Sie die Deployment-Prüfung beim Listener. Laut Dokumentation bindet er standardmäßig an localhost; Multiprocess-Deployments mit einem über --host erreichbaren Listener haben eine andere Grenze. Die Maintainer weisen auch auf ihr früheres Kubernetes-Beispiel hin. Localhost begrenzt Netzwerkerreichbarkeit, authentifiziert aber keinen lokalen Peer. Ermitteln Sie Betriebsmodus, geladene Version, Bind-Adresse und erreichende Clients, bevor Sie den Schweregrad als Bewertung Ihres Deployments behandeln. [1][6]

Aktualisieren Sie kommunizierende Worker und Server gemeinsam, weil sich das Deskriptorformat geändert hat. Eine gemischte Flotte ist nicht die vorgesehene Kompatibilitätsstrategie. Release 0.5.6 dokumentiert die Reparatur; weitere Sicherheitsmaßnahmen führen die Maintainer separat auf. Beschränken Sie den Listener auch nach dem Upgrade. Belegbar ist die Änderung eines bestimmten Rekonstruktionspfads, nicht die Sicherheit des Inferenzdienstes für beliebige Clients. [2][5]

Ein Code Review sollte die Grenze nachweisen

Ein brauchbarer Befund benennt Eingang, eigenen Hook, gefährliche Operation, Voraussetzungen und zu späte Prüfungen. Seine Verifikation sollte die eingesetzte Revision nennen und alle Aufrufer des gemeinsamen Decoders abdecken. Das ist aussagekräftiger als ein Suchtreffer für pickle im Projekt: Das Team weiß, was es ändern muss und wie es die Änderung im Produktivsystem nachweist.

Diese Grenze verfolge ich im Secure Code Review: den Moment, in dem nicht vertrauenswürdige Bytes Verhalten erhalten, und die Annahme, die dieses Verhalten notwendig erscheinen ließ. Wenn Ihre Dienste Objekte durch Caches, Queues oder IPC-Helfer übertragen, beginnen Sie dort. Der schwierige Teil liegt oft mehrere Aufrufe unter dem Endpunkt, den alle bereits für geprüft hielten.