Ce que dit l'avis
Le projet vLLM a révélé CVE-2026-22778 / GHSA-4r2x-xpjr-7cvv en tant que chaîne de vulnérabilité critique du traitement vidéo. L'avis examiné indique qu'un déploiement concerné peut atteindre l'exécution de code à distance lorsqu'il sert un modèle compatible vidéo et traite une entrée vidéo contrôlée par un attaquant. Les déploiements qui ne diffusent pas de modèle vidéo ne sont pas concernés par cet avis. [S1] [S2]
Versions concernées
Les versions PyPI concernées commencent à vLLM 0.8.3 et s'arrêtent avant 0.14.1. PyPA et OSV énumèrent les versions publiées concernées, y compris les versions postérieures et à quatre composants telles que 0.8.5.post1, 0.9.0.1 et 0.10.1.1. vLLM 0.14.1 est la première version corrigée. [S2] [S3] [S4] [S5]
Pourquoi le contexte de déploiement est important
Une dépendance vulnérable est une preuve importante du tri des correctifs, mais ce n’est pas la même chose qu’un service live vulnérable. L'exposition pratique dépend de la version du package déployé, de la question de savoir si ce moteur d'exécution sert un modèle compatible vidéo, si des utilisateurs non fiables peuvent fournir une entrée vidéo et si le chemin de traitement approprié est accessible. [S1]
Comment FixVibe le couvre
Couverts par FixVibe. Les analyses de dépôt GitHub peuvent signaler les preuves de dépendance vLLM affectées à partir des manifestes Python et des fichiers de verrouillage pris en charge dans un référentiel autorisé. Le résultat identifie la source de dépendance, la version ou la plage autorisée, la version corrigée, la confiance et une position de preuve consultative basée sur la version.
FixVibe n'exécute pas vLLM, ne démarre pas un serveur de modèles, n'inspecte pas les capacités du modèle chargé, ne soumet pas ou ne récupère pas de vidéo, n'exerce pas de routes d'inférence, ne teste pas les décodeurs, ne prouve pas la corruption de la mémoire ou ne revendique pas l'exécution de code à distance à partir des preuves du référentiel. La vérification est intentionnellement limitée à une analyse de dépendance sûre.
Correction
Mettez à niveau vLLM vers la version 0.14.1 ou une version ultérieure dans la source de dépendance qui contrôle le déploiement. Régénérez les fichiers de verrouillage actifs et reconstruisez chaque serveur d'inférence, travailleur, bloc-notes, image CI, conteneur de diffusion de modèle, environnement virtuel, cache de roue et cache de package qui l'installe. Vérifiez la version dans l'artefact en cours d'exécution, pas seulement dans le contrôle de code source. [S3] [S5]
Vérifiez si les environnements d'exécution déployés servent des modèles compatibles vidéo ou acceptent l'entrée vidéo. Jusqu'à ce que la version corrigée soit déployée, désactivez ou isolez le traitement vidéo non fiable et restreignez l'accès à la diffusion de modèles. Utilisez des vérifications d'arbre de dépendances, des vérifications de versions d'exécution, des examens de capacités de modèle et des tests de fumée d'inférence bénins ; n’utilisez pas de médias contrefaits ou de tentatives d’exploitation comme vérification. L’avis en amont et les correctifs liés fournissent le contexte de correction faisant autorité. [S1] [S6] [S7] [S8]