CVE-2025-62164 ist eine hochgradig gefährliche Sicherheitslücke in vLLMeiner der am weitesten verbreiteten Open-Source-LLM-Inferenzmaschinen. Das Problem befindet sich innerhalb der Abschlüsse API und wird ausgelöst, wenn der Server die vom Benutzer eingegebene Prompt-Einbettungen. In den betroffenen Versionen (0.10.2 bis einschließlich 0.11.1), deserialisiert vLLM Tensoren mit torch.load() ohne starke Validierung. Ein manipulierter spärlicher Tensor kann durchrutschen und eine unzulässiges Schreiben während der Verdichtungdie den Worker zuverlässig zum Absturz bringt und unter den richtigen Bedingungen zu einer entfernten Codeausführung führen kann. Das Projekt lieferte einen Fix in vLLM 0.11.1. (NVD)

Zwei Dinge unterscheiden diesen CVE von den üblichen KI-Stapelfehlern. Erstens, es ist ein Fehler in der DatenebeneEs handelt sich dabei nicht um eine Admin-UI oder eine Fehlkonfiguration, sondern um einen Exploit-Pfad, der über denselben Inferenz-Endpunkt erreichbar ist, den Ihre Benutzer für die Vervollständigung nutzen. Zweitens befindet er sich genau an der Schnittstelle von unsichere Deserialisierung und vorgelagerte Verhaltensdrifteine Kombination, die mit der Weiterentwicklung der LLM-Infrastruktur immer wieder auftaucht.

Wo vLLM im Stack sitzt - und warum diese Platzierung das Risiko erhöht

vLLM ist praktisch eine durchsatzoptimierte Inferenzschicht. Teams setzen sie als öffentliche SaaS-API, hinter einem Unternehmens-Gateway oder als Serving-Backend für mandantenfähige Agentensysteme ein. In all diesen Layouts ist vLLM nahe am Internet und nahe an den GPU-Ressourcen. Das klingt nach Performance-Engineering; es bedeutet auch API-Aufrufer mit niedrigen Privilegien können privilegierte Codepfade erreichen. (wiz.io)

Der Explosionsradius ist also nicht unbedeutend. Ein einziger absturzfähiger Endpunkt kann zu einem Aushungern der GPUs, zum Aufbau von Warteschlangen, zur Verlagerung von Autoscalern und zu Lärmbelästigungen in der Nachbarschaft führen. Wenn sich die Ausbeutung jemals zu einem RCE stabilisiert, wird die Inferenzflotte zu einem legitimen Stützpunkt für das Eindringen in die Lieferkette.

Die Verwundbarkeit in einem Absatz

Der Completions-Endpunkt in anfälligen vLLM-Versionen ermöglicht es Clients, Folgendes zu übergeben zeitnahe Einbettung anstelle von Rohtext. vLLM rekonstruiert diese Tensoren über torch.load() ohne ausreichende Integritäts-, Typ- oder Strukturprüfungen. Da PyTorch 2.8.0 deaktiviert standardmäßig die Integritätsprüfung von Sparse-Tensorenkann ein bösartiger Spartensensor die internen Schutzmechanismen umgehen und eine Außerhalb der Grenzen des Speichers schreiben, wenn to_dense() heißt. Das unmittelbare, wiederholbare Ergebnis ist Fern-DoS (Absturz des Arbeiters). Mit einer günstigen Speicheranordnung und -steuerung könnte dasselbe Primitiv plausibel umgewandelt werden in RCE auf dem Host. (NVD)

Anatomie der Ursachen: Wie aus "Convenient Embedding Pass-Through" eine Speicherbeschädigung wurde

Eine Deserialisierungssenke auf einem öffentlichen Endpunkt

torch.load() ist von Haus aus leistungsstark. Sie ist dazu gedacht, Tensoren und Objektgraphen aus vertrauenswürdigen Quellen (Prüfpunkte, interne Pipelines) wiederherzustellen. Im Fall von vLLM wird sie für ein Feld verwendet, das von einem API-Aufrufer ausgefüllt werden kann. Damit verschiebt sich die Vertrauensgrenze von "internem Modell-Artefakt" zu "nicht vertrauenswürdiger Internet-Eingabe", was historisch gesehen der Punkt ist, an dem unsichere Deserialisierung scheitert. (NVD)

Auch wenn sich dieses Problem als Speicherbeschädigung und nicht als klassische Pickle-RCE-Kette manifestiert, ist der zugrunde liegende Fehler derselbe: Behandlung einer komplexen binären Struktur, als wäre sie nur ein weiterer Anfrageparameter.

Die PyTorch 2.8.0 Verhaltensänderung war der Funke

Sowohl die vLLM-Beratung als auch der NVD führen die Eskalation auf eine PyTorch-Änderung zurück: Die Integritätsprüfung von Sparse Tensors ist nun standardmäßig deaktiviert. Zuvor war es wahrscheinlicher, dass missgebildete Sparse-Tensoren zurückgewiesen wurden, bevor der Codepfad die Verdichtung erreichte. Mit deaktivierten Prüfungen wurde die fehlende Vorvalidierung von vLLM auf konsistente Art und Weise ausnutzbar. (NVD)

Dies ist ein nützliches mentales Modell für die KI-Infrastruktursicherheit: Durch vorgelagerte Vorgaben kann aus "unsicher, aber ruhend" unbemerkt "unsicher und waffenfähig" werden.

Impact Reality Check: DoS ist garantiert, RCE ist eine Obergrenze

Alle öffentlichen Stellungnahmen stimmen darin überein, dass Remote DoS ist zuverlässig. Eine einzige fehlerhafte Anfrage kann einen Arbeiter töten; wiederholte Anfragen können eine Flotte instabil halten. (ZeroPath)

RCE wird beschrieben als potenziell aus gutem Grund. Die Beschädigung des Speichers bietet einen Weg, aber die Bewaffnung hängt vom Verhalten des Allokators, den Härtungsflags, den Containergrenzen und davon ab, wie viel Kontrolle der Angreifer über den beschädigten Bereich hat. Es gibt kein KAG KEV-Verzeichnis und keine weithin bestätigte "in-the-wild"-Exploit-Kette (Stand: 25. November 2025), aber es wäre ein Fehler, die Beschädigung des Speichers auf der Datenebene als "DoS-only" zu behandeln. (wiz.io)

Betroffene Versionen und Fix-Status

(NVD)

Wer zuerst in Panik geraten sollte: Bedrohungsmodelle, auf die es ankommt

Wenn Sie eine praktische Priorisierung wünschen, überlegen Sie, wo Einbettungen in Ihr System gelangen können.

Öffentliche vLLM-Endpunkte sind der offensichtliche Hochrisikofall. Selbst wenn die Aufrufer einen API-Schlüssel benötigen, ist die Messlatte niedrig: ein normaler Benutzer mit einfachem Zugang kann ausreichen, um Ihre Mitarbeiter zum Absturz zu bringen. (wiz.io)

Als nächstes kommen mandantenfähige "LLM-as-a-Service"-Plattformen. Die Gefahr besteht darin, dass die Einbettungen in indirekt - durch Toolchains, Plugins, Agent-Frameworks oder vorgelagerte Dienste, die Einbettungen als Optimierung durchreichen. Je mehr Stellen Sie Nicht-Text-Payloads akzeptieren, desto komplizierter wird Ihre Vertrauensgrenze.

Und schließlich sollten Sie Community-Demos und Schulungsveranstaltungen nicht außer Acht lassen. Sie sind häufig nicht authentifiziert, werden nicht ausreichend überwacht und sind noch lange nach dem Vergessen des Eigentümers zugänglich.

Sichere Wege zur Bestätigung der Exposition (ohne riskante Probennahme)

Die schnellste Triage ist versionsbasiert.

python -c "import vllm; print(vllm.__version__)"
# betroffen, wenn 0.10.2 <= Version < 0.11.1

(NVD)

Achten Sie auf ein Muster von Fehler bei der Arbeit oder abrupte Neustarts an ungewöhnlich große oder strukturell merkwürdige Abschlussanforderungen gebunden sind. In der Praxis treten Absturzspitzen zuerst auf; eine ausgeklügelte Ausnutzung (wenn sie überhaupt stattfindet) kommt später. (ZeroPath)

Eine harmlose Canary-Prüfung - Standardabschlüsse, kein Durchreichen von Einbettungen - ist nützlich, um die Stabilität von Patches zu überprüfen:

anfragen, json, zeit importieren

HOST = "https:///v1/erledigungen"
headers = {"Authorization": "Bearer "}

payload = {
    "model": "your-model-name",
    "prompt": "health check",
    "max_tokens": 4
}

for i in range(5):
    r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    print(i, r.status_code, r.text[:160])
    time.sleep(1)

Schnell patchen, dann die Datenebene absichern

Die eigentliche Lösung ist ein einfaches Upgrade auf vLLM 0.11.1 oder höher. Alles andere ist ein Notbehelf. (NVD)

Danach sollten Sie "binäre Inferenz-Eingänge" als risikoreiche Senken behandeln. Wenn Ihr Produkt wirklich einen Einbettungs-Pass-Through benötigt, schotten Sie es mit einer strengen Schema-Validierung ab: erzwingen Sie erwartete Tensor-D-Typen, Formen, maximale Größen und verbieten Sie spärliche Formate, wenn Sie sie nicht explizit unterstützen. Sogar eine dumme Zulassen-Liste blockiert die spezifische Klasse von missgebildeten Strukturen, auf die sich diese CVE bezieht. (wiz.io)

Auf der Infrastrukturseite sollten Sie den Explosionsradius einschränken. vLLM-Worker sollten mit den geringsten Privilegien, nach Möglichkeit mit schreibgeschützten Dateisystemen, ohne sensible Host-Mounts und mit Container-Seccomp/AppArmor-Profilen arbeiten. Wenn jemand eine Speicherbeschädigung in eine Codeausführung umwandelt, sollte er in einer Box gefangen sein, die keine Geheimnisse oder Seitenpfade erreichen kann.

Warum CVE-2025-62164 für die KI-Sicherheit als Disziplin wichtig ist

Dieser Vorfall ist ein klares Beispiel dafür, wie sich die KI-Sicherheit von den klassischen Web-App-Playbooks entfernt.

Die neue Grenze ist Modell-Service-DatenebenenTensoren, Einbettungen, multimodale Blobs und serialisierte Artefakte, die sich durch APIs bewegen, weil sie schnell und bequem sind. Sie sind auch strukturell reichhaltig und anfällig - perfekt für Korruptionsfehler, wenn Sie ohne Paranoia deserialisieren.

Es ist auch eine Erinnerung daran, dass die Risikooberfläche eines LLM-Stapels KompositionvLLM hat die Unsicherheit von Sparse Tensors nicht "erfunden"; eine PyTorch-Vorgabe wurde geändert und eine fehlende Validierungsschicht hat diese Änderung in eine CVE verwandelt. Die Entwicklung von Inferenzen erfordert nun das gleiche Maß an Prüfung von Abhängigkeiten, das Kernel-Teams für selbstverständlich halten.

Kontrollierte Validierung, wenn PoCs unübersichtlich oder verspätet sind

CVEs aus der KI-Infrastruktur werden oft vor stabilen öffentlichen PoCs oder mit PoCs veröffentlicht, die zu riskant sind, um sie auf Produktionscluster zu übertragen. Der vertretbare Ansatz ist die Industrialisierung eines sichereren Kreislaufs: maßgebliche Informationen → Hypothese → Validierung nur im Labor → überprüfbarer Nachweis.

In agentenbasierten Arbeitsabläufen im Stil von Penligent können Sie Agenten den vLLM-Beratungs- und NVD-Datensatz aufnehmen lassen, die genauen Expositionsbedingungen ableiten (Versionen, Einbettungspfad, PyTorch-Annahmen) und eine Minimal-Risk-Validierungsplan die Sie nur in einer isolierten Replik ausführen. Auf diese Weise erhalten Sie echte Beweise - Versions-Fingerabdrücke, Absturzsignaturen, Deltas vor und nach Patches - ohne Ihre GPUs zu riskieren. (NVD)

Genauso wichtig ist, dass es mit Hilfe von evidenzbasierten Berichten einfacher ist, der Betriebsleitung die Dringlichkeit zu erklären. "Wir haben gepatcht, weil es in einem Blog steht" hält einer Überprüfung nicht stand. "Wir haben gepatcht, weil unsere Laborreplik über den anfälligen Einbettungspfad zum Absturz gebracht werden kann, und hier ist die Zeitleiste und der Diff nach dem Upgrade auf 0.11.1" schon.CVE-2025-62164 PoC: vLLM's Completions Data-Plane Bug, der Einbettungen in eine Angriffsfläche verwandelt