vLLM laisse une image EPS déguisée en PNG atteindre Ghostscript et exécuter du code

20 octobre 2026. Le projet vLLM publie l’avis GHSA-h3rc-j82p-2c3h, qui documente la CVE-2026-115915 : un chemin d’exécution de code par l’image. 18 octobre 2026. La version 0.32.0 corrigeait déjà la faille en limitant les images non fiables aux formats raster. 2 mai 2024. Ghostscript avait corrigé la CVE-2024-29510, la faille de format de chaîne que la CVE-2026-115915 réactive. Le point qui compte : un serveur d’inférence qui accepte des images transforme le décodeur d’images — et tout ce qu’il appelle — en surface d’attaque distante.

Un serveur de modèles devient un lecteur d’images

vLLM est le moteur de serving de modèles LLM le plus déployé en auto-hébergement, derrière l’API compatible OpenAI de nombreux clusters GPU. Les modèles multimodaux — capables de lire une image jointe à une requête — obligent le serveur à décoder cette image avant de la transmettre au modèle. C’est exactement là que vit la faille.

Dans vLLM 0.30.0, le composant ImageMediaIO transmettait les octets contrôlés par l’attaquant à la détection de format automatique de Pillow, sans restreindre les formats acceptés. L’en-tête MIME de la requête — image/png par exemple — ne contraignait pas le décodeur réellement utilisé. Un fichier EPS étiqueté image/png franchissait donc l’étiquette et atteignait le gestionnaire EPS de Pillow, qui appelle l’exécutable Ghostscript de l’hôte.

L’exécution de code exige un second défaut, plus ancien. Sur un hôte dont Ghostscript est affecté par la CVE-2024-29510 — une faille de format de chaîne présente de Ghostscript 9.50 à 10.03.0 et qui contourne le bac à sable -dSAFER — le fichier EPS peut exécuter des commandes avec les privilèges du processus vLLM. L’auteur de l’avis a reproduit l’exécution de commandes au niveau du chargeur avec la roue PyPI vllm==0.30.0, Pillow 12.3.0 et Ghostscript 10.03.0 de Debian.

Ghostscript n’est pas installé par vLLM — mais votre image de base l’est peut-être

Le piège est précisément là : les dépendances de vLLM ne déclarent pas Ghostscript. Le projet n’installe donc jamais l’exécutable fautif. Mais une image CUDA bâtie sur une distribution généraliste, ou enrichie d’un outillage documentaire — un sidecar d’ingestion PDF, par exemple — le transporte sans que personne ne l’ait demandé. La faille ne se déclenche que si les deux conditions coïncident : un modèle multimodal exposé, et un Ghostscript vulnérable présent dans le conteneur.

C’est ce décalage qui rend la CVE-2026-115915 insidieuse. Un scanner de vulnérabilités ne verra rien dans pip list : Ghostscript n’y figure pas. Il faut inspecter l’image elle-même. Le même avis décrit par ailleurs un déni de service autonome, la CVE-2026-59203, dans Pillow 12.0.0 à 12.2.0 : un compteur d’octets négatif dans un fichier EPS fait boucler l’analyseur à l’intérieur de Image.open(). Lors du test du rapporteur, huit chargements malveillants simultanés ont saturé tous les threads de chargement multimédia et bloqué une requête légitime.

La correction : limiter aux formats raster

La version 0.32.0, publiée le 18 octobre, règle le problème à la racine. La note de version résume le correctif en une ligne : « untrusted images are limited to raster formats » — les images non fiables sont restreintes aux formats raster. Le chemin EPS est fermé, et la liste des formats acceptés cesse de dépendre de la confiance accordée à l’étiquette MIME.

Deux détails compliquent la mise à niveau. D’abord, vLLM 0.30.0 ne figeait pas la version de Pillow : mettre à jour vLLM seul peut laisser un Pillow vulnérable en place. Il faut viser Pillow 12.3.0 ou plus, qui ferme la boucle CVE-2026-59203. Ensuite, l’image conteneur compte autant que le numéro de version : reconstruire l’image sans Ghostscript — ou avec une version 10.03.1 ou plus — élimine le second étage, même si une future régression rouvrait le premier.

La CVE-2026-115915 n’est pas le premier signal sur cet écosystème. Ce blog a couvert la RCE de LMCache par désérialisation pickle sur les serveurs vLLM, et la faille de Pillow déclenchée par le nom de fichier. La leçon transversale est la même : la frontière d’un moteur d’inférence ne s’arrête pas aux prompts — elle englobe tout décodeur tiers qui traite des octets contrôlés par l’utilisateur.

Verdict

Si vous exposez un serveur vLLM avec un modèle multimodal, passez en 0.32.0 cette semaine et reconstruisez l’image conteneur sans Ghostscript vulnérable : c’est la seule correction qui couvre les deux étages de la chaîne. Si vous ne savez pas si vos images de base embarquent Ghostscript, lancez un dpkg -l ghostscript ou un rpm -q ghostscript dans le conteneur d’inférence — l’absence de dépendance déclarée ne prouve rien. Et si vous servez aussi des clients tiers, traitez l’image jointe comme du non fiable au même titre que le prompt : limitez les formats acceptés à la passerelle, ne faites jamais confiance à l’en-tête MIME, et surveillez les avis de vLLM, qui en a publié dix entre le 23 septembre et le 20 octobre. La faille de l’image est le symptôme d’une frontière de confiance mal posée — la corriger revient à la redessiner.

Références

• GitHub — vLLM Security Advisory GHSA-h3rc-j82p-2c3h (CVE-2026-115915)
• GitLab Advisories — vLLM : CVE-2026-115915
• NVD — CVE-2026-115915
• Codean Labs — CVE-2024-29510 : Ghostscript format string exploitation
• vLLM — Release notes 0.32.0
• Beri.net — vLLM 0.30.0 Can Run Code Through Ghostscript Images (26 octobre 2026)
• ETTAYEB — Pillow 13.0 corrige une exécution de commandes déclenchée par le nom du fichier
• ETTAYEB — LMCache expose une RCE critique non corrigée via un simple message ZeroMQ sur les serveurs vLLM