Was in der Empfehlung steht
Das vLLM-Projekt hat CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv als kritische Schwachstellenkette bei der Videoverarbeitung offengelegt. In der überprüften Empfehlung heißt es, dass eine betroffene Bereitstellung eine Remote-Codeausführung erreichen kann, wenn sie ein videofähiges Modell bereitstellt und vom Angreifer kontrollierte Videoeingaben verarbeitet. Bereitstellungen, die kein Videomodell unterstützen, sind von dieser Empfehlung nicht betroffen. [S1] [S2]
Betroffene Veröffentlichungen
Die betroffenen PyPI-Versionen beginnen bei vLLM 0.8.3 und enden vor 0.14.1. PyPA und OSV zählen die betroffenen veröffentlichten Releases auf, einschließlich Post- und Vierkomponenten-Releases wie 0.8.5.post1, 0.9.0.1 und 0.10.1.1. vLLM 0.14.1 ist die erste feste Version. [S2] [S3] [S4] [S5]
Warum der Bereitstellungskontext wichtig ist
Eine anfällige Abhängigkeit ist ein wichtiger Patch-Triage-Beweis, aber sie ist nicht dasselbe wie ein anfälliger Live-Dienst. Die praktische Verfügbarkeit hängt von der bereitgestellten Paketversion ab, davon, ob diese Laufzeit ein videofähiges Modell bedient, ob nicht vertrauenswürdige Benutzer Videoeingaben bereitstellen können und ob der relevante Verarbeitungspfad erreichbar ist. [S1]
Wie FixVibe es abdeckt
Abgedeckt durch FixVibe. GitHub-Repo-Scans können betroffene vLLM-Abhängigkeitsnachweise aus unterstützten Python-Manifesten und Sperrdateien in einem autorisierten Repository melden. Das Ergebnis identifiziert die Abhängigkeitsquelle, die Version oder den zulässigen Bereich, die feste Version, die Konfidenz und eine versionbasierte beratende Beweislage.
FixVibe führt kein vLLM aus, startet keinen Modellserver, prüft die Funktionen geladener Modelle nicht, übermittelt oder ruft kein Video ab, führt keine Inferenzrouten aus, führt keine Crashtest-Decoder durch, weist keine Speicherbeschädigung nach und beansprucht keine Remotecodeausführung anhand von Repository-Beweisen. Die Prüfung beschränkt sich bewusst auf die sichere Abhängigkeitsanalyse.
Sanierung
Aktualisieren Sie vLLM auf 0.14.1 oder höher in der Abhängigkeitsquelle, die die Bereitstellung steuert. Generieren Sie aktive Sperrdateien neu und erstellen Sie alle Inferenzserver, Worker, Notebooks, CI-Images, Model-Serving-Container, virtuellen Umgebungen, Wheel-Cache und Paket-Cache neu, die sie installieren. Überprüfen Sie die Version im laufenden Artefakt, nicht nur in der Quellcodeverwaltung. [S3] [S5]
Überprüfen Sie, ob bereitgestellte Laufzeiten videofähige Modelle bedienen oder Videoeingaben akzeptieren. Bis der feste Build bereitgestellt wird, deaktivieren oder isolieren Sie nicht vertrauenswürdige Videoverarbeitung und beschränken Sie den Zugriff auf die Modellbereitstellung. Verwenden Sie Abhängigkeitsbaumprüfungen, Laufzeitversionsprüfungen, Überprüfung der Modellfähigkeit und harmlose Inferenzrauchtests. Verwenden Sie keine manipulierten Medien oder Verwertungsversuche als Nachweis. Die Upstream-Beratung und die verknüpften Fixes stellen den maßgeblichen Korrekturkontext bereit. [S1] [S6] [S7] [S8]