Eine neu entdeckte Schwachstelle durch Speicherbeschädigung in vLLM könnte es Angreifern ermöglichen, Server zum Absturz zu bringen oder beliebigen Code auszuführen, indem sie manipulierte Prompt-Embeddings an die Completions-API senden.
Die Schwachstelle betrifft vLLM-Versionen ab 0.10.2 und setzt produktive KI-Bereitstellungen einem unmittelbaren Risiko aus.
„Die Schwachstelle ermöglicht es jedem Benutzer mit Zugriff auf die API, im vLLM-Serverprozess potenziell einen Denial-of-Service und eine Remote-Code-Ausführung zu erreichen“, sagten Sicherheitsforscher von Wiz.
Die Ursache des vLLM-Fehlers verstehen
Die Schwachstelle (CVE-2025-62164) geht auf die Art und Weise zurück, wie vLLM benutzerseitig bereitgestellte Prompt-Embeddings verarbeitet – eine Funktion, mit der fortgeschrittene Anwendungen vorab berechnete Vektoren direkt an das Modell übergeben können.
Wenn ein Client ein Embedding an die Completions-API sendet, versucht vLLM, den Tensor zu rekonstruieren, indem die Base64-codierte Nutzlast mithilfe der torch.load()-Funktion von PyTorch deserialisiert wird.
Das Problem tritt in entrypoints/renderer.py auf, wo vLLM das Base64-codierte Embedding decodiert und mithilfe von torch.load() deserialisiert.
Nach dem Laden des Tensors wandelt der Server ihn sofort mit to_dense() in einen dichten Tensor um – ohne zuvor Integritäts- oder Sicherheitsprüfungen durchzuführen.
In diesem Teil des Codes übernimmt vLLM einfach das vom Benutzer bereitgestellte Embedding, lädt es über torch.load(io.BytesIO(pybase64.b64decode(embed, validate=True)), weights_only=True, map_location=torch.device(“cpu”)) und führt anschließend tensor = tensor.to_dense() aus, ohne dazwischen eine Validierung vorzunehmen.
Da vLLM an diesem Punkt davon ausgeht, dass der Tensor gültig und sicher ist, kann jede manipulierte Nutzlast den Deserialisierungsschritt passieren und während der Verdichtung eine Speicherbeschädigung verursachen, was einen Denial-of-Service oder möglicherweise eine Remote-Code-Ausführung ermöglicht.
Die PyTorch-Änderung, die dies ermöglichte
In PyTorch 2.8.0 deaktivierte das Framework standardmäßig die Integritätsprüfungen für Sparse-Tensoren und entfernte damit Schutzmechanismen, die zuvor die Indexgrenzen, die Konsistenz der Tensorform und die internen Invarianten überprüften, die vor dem Aufruf von to_dense() erforderlich sind.
Diese Prüfungen müssen nun mithilfe von torch.sparse.check_sparse_tensor_invariants ausdrücklich wieder aktiviert werden, doch vLLM implementiert diesen Schutz nicht.
Dadurch kann ein Angreifer einen fehlerhaften Sparse-Tensor mit internen Indizes erstellen, die außerhalb der erwarteten Speicherbereiche liegen.
PyTorch lädt den Tensor weiterhin erfolgreich, doch wenn vLLM später to_dense() aufruft, versucht das Framework, den fehlerhaften Tensor vollständig im dichten Speicher zu materialisieren, was einen Schreibvorgang außerhalb der zulässigen Grenzen verursacht und potenziell eine Speicherbeschädigung ermöglicht.
Was Angreifer mit dieser vLLM-Schwachstelle tun können
Je nachdem, wie die manipulierte Nutzlast erstellt wurde, kann der Schreibvorgang außerhalb der zulässigen Grenzen mehrere schwerwiegende Folgen haben.
Er kann den Server zum Absturz bringen und einen Denial-of-Service-Zustand (DoS) verursachen, wenn kritischer Ausführungsspeicher beschädigt wird.
In fortgeschritteneren Fällen könnte ein Angreifer beliebigen Code ausführen, indem er Speicherbereiche überschreibt, die den Kontrollfluss beeinflussen.
Dies eröffnet außerdem die Möglichkeit einer lateralen Kompromittierung innerhalb des KI-Stacks, da vLLM häufig neben sensiblen Komponenten wie GPUs, Modellgewichten, Protokollen oder proprietären Daten ausgeführt wird.
Da der anfällige Deserialisierungspfad über die öffentlich zugängliche Completions-API erreichbar ist, benötigt ein Angreifer weder erhöhte Berechtigungen noch vorherigen Zugriff – er muss lediglich in der Lage sein, Embedding-Nutzlasten an den Server zu senden.
Die Deserialisierungsschwachstelle im Detail
Diese Exploit-Kette ist ein Fall unsicherer Deserialisierung, bei der nicht vertrauenswürdige Eingaben direkt in Objekte im Arbeitsspeicher rekonstruiert werden. Im Fall von vLLM wird das Risiko durch folgende Faktoren verstärkt:
- Die Deserialisierung von Tensoren ist komplex und speicherintensiv.
- Die Embedding-Nutzlast durchläuft keine Validierungsschicht.
- Die zugrunde liegende Bibliothek (PyTorch) lässt fehlerhafte Daten stillschweigend zu.
Kurz gesagt: Das System nimmt vom Angreifer kontrollierte Bytes, rekonstruiert sie zu einem Sparse-Tensor und weist PyTorch anschließend an, diesen Tensor in dichten Speicher zu expandieren – ohne zu überprüfen, ob der Tensor die erforderlichen Invarianten erfüllt.
Wichtige Schritte zur Eindämmung der vLLM-Schwachstelle
Angesichts des Schweregrads der vLLM-Deserialisierungsschwachstelle müssen Sicherheitsteams eine mehrschichtige Eindämmungsstrategie umsetzen, um das Risiko einer Serverkompromittierung zu verringern.
- Auf die gepatchte vLLM-Version aktualisieren und die Integritätsprüfungen für Sparse-Tensoren von PyTorch anwenden, um unsichere Deserialisierung zu verhindern.
- Den Zugriff auf die Completions-API einschränken und authentifizieren, indem die öffentliche Erreichbarkeit entfernt, eine starke Authentifizierung erzwungen und eine Ratenbegrenzung eingesetzt wird.
- Alle Prompt-Embeddings validieren und filtern – über ein API-Gateway, eine WAF oder Middleware, um fehlerhafte oder nicht vertrauenswürdige Tensoren abzufangen, bevor sie vLLM erreichen.
- vLLM in gehärteten Umgebungen isolieren – etwa in dedizierten Containern oder virtuellen Maschinen – und dabei das Prinzip der geringsten Berechtigung, Segmentierung und nicht privilegierte Dienstkonten verwenden.
- Überwachung und Protokollierung auf Anzeichen einer Ausnutzung aktivieren, darunter Abstürze, fehlerhafte Embeddings, Deserialisierungsfehler und anomales Inferenzverhalten.
- Die Laufzeit- und Infrastruktursicherheit stärken durch den Einsatz von ASLR, DEP/NX, Netzwerksegmentierung, Zugriffskontrollen und regelmäßigen Sicherheitstests wie Fuzzing sowie Audits der Abhängigkeiten.
Mehrschichtige Abwehrmaßnahmen, kontinuierliche Überwachung und Security-by-Design-Prinzipien tragen dazu bei, dass zukünftige Bedrohungen früher erkannt und wirksamer eingedämmt werden.
KI-Infrastruktur wird zum bevorzugten Ziel
Diese Schwachstelle unterstreicht ein wachsendes Thema der KI-Sicherheit: Die Angriffsfläche umfasst nicht nur das Modell – sie schließt auch den verbindenden Code, Inferenz-Engines, Serialisierungsbibliotheken und Datenpipelines ein, die es umgeben.
Da Organisationen immer mehr LLM-gestützte Funktionen einsetzen, werden Schwachstellen in unterstützenden Frameworks wie vLLM und PyTorch sowie in APIs zur Modellbereitstellung zunehmend attraktive Ziele.
Der Vorfall zeigt außerdem, wie subtile Änderungen an vorgelagerten Komponenten – in diesem Fall die Deaktivierung von Integritätsprüfungen durch PyTorch – Sicherheitslücken schaffen können, die sich durch das gesamte KI-Ökosystem ziehen.
Da die KI-Infrastruktur modularer und stärker vernetzt wird, können selbst kleinere Deserialisierungsschwachstellen zu einer vollständigen Kompromittierung eskalieren, wenn Unternehmen keine Patches anwenden und keine strikte Eingabevalidierung durchsetzen.