L'entrée multimodale comme surface d'attaque : la RCE du décodeur vidéo de vLLM (CVE-2026-22778)
CVE-2026-22778 transforme une URL vidéo malveillante en exécution de code à distance sur les serveurs vLLM, en chaînant une fuite d'info PIL et un débordement de tas dans le décodeur JPEG2000 de FFmpeg. Corrigé en 0.14.1.
En bref L’essentiel des écrits sur la sécurité des LLM porte sur les prompts. CVE-2026-22778 rappelle que le pipeline de décodage des médias d’un serveur d’inférence est lui aussi une surface d’attaque. Une vidéo malveillante envoyée à un endpoint vLLM servant un modèle vidéo peut chaîner une fuite d’adresse mémoire et un débordement de tas dans un décodeur natif embarqué pour aboutir à une exécution de code à distance — sans aucune injection de prompt. Sont concernées les versions vLLM
0.8.3à0.14.0; le correctif est en 0.14.1. vLLM est livré sans authentification par défaut, ce qui rend les déploiements exposés directement atteignables.
De quoi s’agit-il ?
vLLM est l’un des moteurs les plus déployés pour servir des grands modèles de langage, avec un paquet Python téléchargé plus de trois millions de fois par mois. Lorsqu’il sert un modèle multimodal, l’entrée utilisateur n’est plus seulement du texte : images et vidéos sont soumises à l’API et décodées avant d’atteindre le modèle.
CVE-2026-22778 (advisory GitHub GHSA-4r2x-xpjr-7cvv), analysée publiquement par OX Security dans une publication parue le 2 février 2026 et suivie depuis dans la NVD et plusieurs bases de vulnérabilités, est un bug d’exécution de code à distance dans ce chemin de décodage. Un attaquant capable de soumettre une URL vidéo forgée à une instance vLLM servant un modèle vidéo peut exécuter des commandes arbitraires sur l’hôte. Les déploiements qui ne servent pas de modèle vidéo ne sont pas affectés.
Comment ça fonctionne
Le problème divulgué est un exploit chaîné — deux faiblesses séparées, faibles isolément mais dévastatrices ensemble. Nous en décrivons le mécanisme au niveau conceptuel ; aucun payload fonctionnel n’est reproduit ici.
Le premier maillon est une fuite d’information. Lorsqu’une image invalide est envoyée à l’endpoint multimodal, la bibliothèque PIL lève une erreur dont le message est renvoyé au client. Ce message inclut une adresse mémoire de tas. Fuiter une seule adresse valide effondre l’espace de recherche que l’ASLR (Address Space Layout Randomisation) est censée protéger — les défenseurs ont décrit l’effet comme la réduction d’environ quatre milliards de possibilités à une poignée.
Le second maillon est un débordement de tas dans le décodeur JPEG2000. vLLM utilise OpenCV pour décoder les vidéos, et OpenCV embarque FFmpeg 5.1.x. Le décodeur JPEG2000 fait confiance aux métadonnées de définition de canaux (cdef) de l’image pour remapper les canaux de couleur sans revalider les tailles de tampon : des données destinées à un canal peuvent ainsi être écrites dans le tampon plus petit d’un autre, débordant sur la mémoire de tas adjacente. Comme l’attaquant contrôle à la fois la géométrie de l’image et le mappage des canaux, il contrôle la quantité de mémoire écrasée et les objets voisins touchés. Combiné à l’adresse fuitée à l’étape précédente, ce contrôle suffit à écraser un pointeur de fonction et à rediriger l’exécution vers une routine de la libc telle que system().
Le déclencheur est un usage ordinaire de l’API : une URL vidéo passée à un appel de complétion ou d’invocation pour un modèle vidéo. Une instance vLLM installée par défaut via pip ou Docker n’a aucune authentification, donc un endpoint exposé sur Internet peut être atteint directement.
Pourquoi c’est important
La leçon dépasse largement cette seule CVE. Les équipes raisonnent intensément sur l’injection de prompt et les jailbreaks, puis transmettent des images et des vidéos non fiables directement à des décodeurs natifs C/C++ — du code au long historique de bugs de sûreté mémoire — qui s’exécutent dans le même processus que le modèle et ses secrets. La partie « IA » de la pile hérite de tous les risques classiques de corruption mémoire des bibliothèques de traitement média sous-jacentes.
Le rayon d’impact est large à cause de la position des serveurs d’inférence : proches des GPU, des poids des modèles, des réseaux internes et des clés d’API. Une RCE à cet endroit signifie prise de contrôle complète du serveur, exfiltration de données et déplacement latéral. Et le débordement résidait dans une dépendance tierce embarquée, si bien qu’une organisation peut être exposée sans avoir jamais écrit ni relu la ligne vulnérable. À la divulgation, aucune preuve d’exploitation dans la nature n’était publique, mais la plage affectée couvre de nombreuses versions.
Défenses
- Mettez à jour vers vLLM 0.14.1 ou ultérieur. Le correctif a été déployé via les pull requests #31987, #32319 et #32668 — il assainit les messages d’erreur qui fuitent et met à jour le décodeur vulnérable. Vérifiez votre version avec
pip show vllm. - Désactivez la fonctionnalité de modèle vidéo en production jusqu’au correctif si vous ne pouvez pas mettre à jour immédiatement. Les déploiements ne servant que du texte ou des images via les chemins corrigés ne sont pas exposés à cette chaîne précise.
- N’exposez jamais un endpoint vLLM brut à des réseaux non fiables. vLLM n’a pas d’authentification par défaut ; placez-le derrière une passerelle authentifiée, restreignez l’entrée, et traitez chaque média téléversé comme une entrée hostile.
- Isolez (sandbox) la couche de décodage et d’inférence. Faites tourner le service dans un conteneur minimal à sortie réseau restreinte et à privilèges minimaux, segmenté des magasins de données sensibles, afin qu’une compromission du décodeur ne puisse pas pivoter vers le reste de l’environnement.
- Ne renvoyez pas les erreurs brutes des bibliothèques aux clients. Fuiter le texte d’exception — adresses, frames de pile, chemins — est une primitive de fuite d’info récurrente. Interceptez et remplacez les messages d’erreur internes à la frontière de l’API.
- Suivez vos dépendances natives. Les décodeurs d’images et de vidéos (OpenCV, FFmpeg, PIL) font partie de votre surface d’attaque LLM. Épinglez-les et surveillez-les dans votre SBOM, et corrigez-les avec la même urgence que le framework du modèle lui-même.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Advisory CVE-2026-22778 | GitHub (GHSA-4r2x-xpjr-7cvv) | 2026 | Fuite d’info + débordement de tas chaînés, RCE via vidéo |
| Analyse technique publique | OX Security | 2026-02-02 | Fuite d’adresse PIL + débordement JPEG2000 FFmpeg |
| Versions affectées | vLLM | 0.8.3 → 0.14.0 | Uniquement les déploiements servant un modèle vidéo |
| Version corrigée | vLLM 0.14.1 | — | Correctif PR #31987, #32319, #32668 |
Le bon cadrage n’est pas « une CVE vLLM de plus ». C’est que les endpoints multimodaux étendent discrètement la surface d’attaque d’un service LLM jusqu’à du code média natif vieux de plusieurs décennies — et cette surface mérite la même isolation, la même défiance vis-à-vis des entrées et la même hygiène des dépendances que n’importe quel autre parseur non fiable.