vLLM 0.32.0 : huit CVE en une fois, dont une exécution de code via une image EPS et Ghostscript

vLLM 0.32.0 : huit CVE en une fois, dont une exécution de code via une image EPS et Ghostscript

🔎 Huit avis le même jour, et beaucoup de serveurs qui ne bougeront pas

Le 20 octobre 2026, le projet vLLM a publié huit avis de sécurité d'un coup, tous corrigés par la version 0.32.0. Ajoutés à la GitHub Advisory Database le 28 octobre, ils s'inscrivent dans une série qui compte désormais 12 pages d'avis sur le dépôt du projet, dont 10 publiés entre le 23 septembre et le 20 octobre. Ce n'est plus un incident isolé : c'est un rythme.

Le plus sérieux du lot, CVE-2026-115915 (CVSS 8.1, High), permet à un simple utilisateur d'un endpoint d'inférence d'exécuter du code sur la machine hôte — en envoyant une image EPS déguisée en PNG, qui finit entre les mains d'un Ghostscript vulnérable installé sur le host. Une seule requête, du code exécuté avec les privilèges du processus vLLM.

Si vous auto-hébergez vLLM — pour servir un modèle en interne, alimenter un agent, ou simplement éviter les coûts d'API — cet article est votre checklist. Nous détaillons les trois CVE les plus structurantes, le reste du lot, et surtout la procédure de mise à jour concrète. Zéro alarmisme : les faits, les versions, les commandes.

Sources principales : l'analyse de beri.net, la fiche NVD de CVE-2026-115915 et la page des avis de sécurité du projet vLLM.

L'essentiel

• CVE-2026-115915 (CVSS 8.1, High) : une charge EPS étiquetée image/png contourne la détection de format de Pillow et atteint l'exécutable Ghostscript du host. Sur un host affecté par CVE-2024-29510, cela donne une évasion de sandbox Ghostscript et une exécution de commandes avec les privilèges du processus vLLM. Corrigé en 0.32.0.
• CVE-2026-115916 (CVSS 6.5) : une erreur off-by-one dans vllm/tokenizers/hf.py laisse passer un token ID hors vocabulaire, provoquant un CUDA device-side assert et un crash complet de l'engine. Corrigé en 0.32.0.
• CVE-2026-115917 (CVSS 3.4) : CORS wildcard par défaut (allowed_origins = *) sur le serveur compatible OpenAI, sans authentification sauf si --api-key ou VLLM_API_KEY est configuré. N'importe quelle page web peut appeler votre serveur depuis le navigateur de vos utilisateurs. Corrigé en 0.32.0.
• CVE-2026-115912 (CVSS 7.5, High) : un handle de mémoire partagée forgé atteint pickle.loads — un second chemin d'exécution de code arbitraire. Corrigé en 0.32.0.
• La version 0.32.0 couvre tout le lot d'octobre. Les avis plus anciens (RCE via code_revision, hang via min_tokens, crash cross-tenant via logprobs) ont été corrigés en 0.31.0. Si vous êtes resté en 0.30.x, vous cumulez les deux vagues.
• Checklist rapide : pip show vllm (visez ≥ 0.32.0), gs --version (10.03.1 ou plus récent, sinon votre host est vulnérable à l'évasion de sandbox), Pillow ≥ 12.3.0, et une clé API systématique.

Outils recommandés

Pour auditer et sécuriser une stack d'inférence self-hosted, voici ce que nous utilisons et recommandons :

CVE-2026-115915 : une image EPS déguisée qui finit en exécution de code (CVSS 8.1)

Réponse directe : oui, un utilisateur de votre API peut exécuter du code sur votre serveur en envoyant une seule image malformée — si votre host tourne avec un Ghostscript vulnérable. C'est la CVE la plus sérieuse du lot, notée High avec un CVSS de 8.1 selon NVD.

La chaîne d'exploitation, étape par étape

Le problème se situe dans le module ImageMediaIO de vLLM, présent au moins depuis la version 0.30.0. Quand une image arrive via une requête multimodale, vLLM passe les octets bruts à la détection automatique de format de Pillow — sans liste blanche. Pillow examine les octets, devine le format, et délègue le décodage au bon handler.

Le piège : PostScript et EPS sont des formats que Pillow sait reconnaître, mais qu'il ne décode pas lui-même. Il délègue à l'exécutable Ghostscript installé sur le host. Un attaquant peut donc envoyer une charge EPS en prétendant qu'il s'agit d'une image/png dans les métadonnées de la requête. La détection automatique de Pillow voit les octets EPS, délègue à Ghostscript, et votre serveur exécute du PostScript fourni par un utilisateur.

C'est déjà fâcheux. Mais ça devient critique quand le Ghostscript du host est lui-même vulnérable. Le scénario reproduit dans l'analyse de l'advisory GitLab combine vLLM avec un Ghostscript Debian 10.03.0 affecté par CVE-2024-29510 — une évasion de sandbox connue de Ghostscript. Résultat : exécution de commandes avec les privilèges du processus vLLM. Sur la plupart des déploiements Docker, cela signifie root dans le conteneur, et souvent bien au-delà si les montages sont permissifs.

Pourquoi c'est grave même sans exposition internet

Beaucoup d'équipes pensent « mon vLLM n'est exposé qu'en interne, donc pas de risque ». Deux objections à cela.

D'abord, « interne » signifie souvent que des dizaines de développeurs, des notebooks Jupyter et des agents peuvent envoyer des requêtes. Il suffit qu'un de ces postes soit compromis — et l'extension VS Code malveillante qui a compromis 3 800 repos internes chez GitHub en 2026 montre à quelle vitesse un poste de développeur peut devenir la porte d'entrée — pour que l'attaquant hérite d'un accès à votre GPU et à votre host.

Ensuite, les modèles multimodaux sont devenus la norme, pas l'exception. Les modèles qui raisonnent sur des images et des vidéos, comme ceux dont nous avons parlé avec Elorian Glimpse, rendent le pipeline de traitement d'images obligatoire. Plus votre modèle accepte d'inputs, plus votre surface d'attaque grandit. Le traitement d'image n'est plus une option qu'on peut désactiver pour se simplifier la vie.

Le correctif : vLLM 0.32.0. En défense en profondeur, mettez aussi Ghostscript à jour vers 10.03.1 ou plus récent (les versions sous 10.03.1 restent vulnérables à l'évasion de sandbox) et Pillow vers 12.3.0+, qui rejette désormais l'échantillon EPS bouclé utilisé comme preuve de concept.

CVE-2026-115916 : un token ID et tout l'engine s'effondre (CVSS 6.5)

Réponse directe : oui, un seul token ID mal formé peut faire planter l'intégralité de votre moteur d'inférence, toutes les requêtes en cours comprises. Pas d'exécution de code ici, mais un déni de service trivial à déclencher et difficile à diagnostiquer.

La faille, tracée sous GHSA-q97c-p368-75c4, est une erreur off-by-one dans vllm/tokenizers/hf.py. Le code de validation accepte un token ID prétokenisé égal à la taille du vocabulaire — alors que les IDs valides vont de 0 à vocab_size - 1. Ce token invalide n'est pas masqué avant d'atteindre F.embedding, et dans une configuration à tensor-parallel 1 avec un vocabulaire multiple de 64 (le cas de la plupart des modèles grand public), la couche d'embedding lève un CUDA device-side assert.

Concrètement, un assert CUDA ne se contente pas de rejeter une requête : il corrompt l'état du contexte CUDA. L'engine entier crash. Sur un serveur qui traite des centaines de requêtes concurrentes, un utilisateur — volontairement ou par un bug côté client — peut mettre à terre la file d'attente complète.

Ce qui rend cette CVE particulièrement instructive, c'est sa banalité. Une comparaison >= au lieu de > dans une validation d'entrée, et voilà un vecteur de déni de service sur l'infrastructure la plus chère de votre stack. Le CVSS de 6.5 reflète cette réalité : pas de compromission, mais une disponibilité détruite à volonté. Corrigé en 0.32.0.

CVE-2026-115917 : CORS wildcard, ou comment le navigateur de vos utilisateurs consomme votre GPU (CVSS 3.4)

Réponse directe : oui, n'importe quelle page web visitée par un de vos employés peut appeler votre serveur vLLM non authentifié depuis son navigateur — lister vos modèles et lancer des requêtes sur votre GPU. Le CVSS de 3.4 est bas, mais ne vous y trompez pas : c'est la CVE la plus facile à exploiter du lot.

Le serveur compatible OpenAI de vLLM a un comportement par défaut permissif : allowed_origins = * en CORS, et aucune authentification sauf si vous configurez explicitement --api-key ou la variable d'environnement VLLM_API_KEY. Conséquence documentée dans l'avis OpenCVE : une page web malveillante — un site de phishing, une publicité, un article piégé — peut faire des requêtes GET /v1/models et POST /v1/chat/completions vers votre serveur interne depuis le navigateur d'un employé qui visite cette page.

Le navigateur envoie la requête, vLLM répond avec les headers CORS wildcard, le navigateur accepte la réponse. L'attaquant ne voit pas le contenu, mais il déclenche l'exécution. Sur un endpoint d'inférence, cela signifie : énumération de vos modèles déployés (une information sensible en soi) et consommation de votre capacité GPU à votre insu. À l'échelle d'une équipe, quelques onglets ouverts suffisent à dégrader votre latence de production.

Le CVSS de 3.4 sous-estime selon nous l'impact réel en entreprise, parce qu'il ne modélise pas bien le scénario « serveur interne + navigateurs du LAN ». Le correctif est livré en 0.32.0, mais la vraie leçon est plus large : un serveur d'inférence sans authentification n'est pas un serveur interne, c'est un serveur ouvert à tout ce qui peut atteindre le réseau — y compris les navigateurs. Configurez --api-key systématiquement, et ajoutez un reverse proxy avec authentification si l'endpoint est partagé.

Le reste du lot : SHM forgé, pickle.loads et cinq avis medium

Réponse directe : le batch d'octobre compte deux avis High, cinq medium et un low — et le second High mérite presque autant d'attention que le premier.

Selon l'analyse d'Agentbeam, voici la répartition :

Le cas CVE-2026-115912 mérite un mot. La désérialisation via pickle.loads est un classique des failles Python : pickle n'est pas un format de données, c'est un format d'exécution. Un handle de mémoire partagée forgé qui atteint un pickle.loads est un chemin direct vers l'exécution de code arbitraire. Le CVSS de 7.5 est cohérent — l'exploitation exige probablement un accès local ou un scénario multi-tenant, mais dans un déploiement qui partage une machine entre plusieurs équipes, ce n'est pas une hypothèse exotique.

Les cinq avis medium couvrent des dénis de service et des contournements de gate (les mécanismes de restriction de vLLM, comme les limites de tokens ou les filtres d'entrée). Individuellement, chacun semble mineur. Cumulés, ils dessinent un constat : la couche de validation d'entrée de vLLM a été repensée en profondeur entre 0.30 et 0.32, et rester sur une ancienne version signifie empiler les vecteurs d'attaque.

Checklist de mise à jour pour une installation self-hosted

Réponse directe : la version 0.32.0 couvre tout le lot d'octobre, et la 0.31.0 couvre la vague précédente. Si vous êtes en 0.30.x ou moins, vous cumulez. Voici la procédure que nous recommandons, dans l'ordre.

Étape 1 : état des lieux

pip show vllm
gs --version
pip show pillow

Trois vérifications à effectuer :

• vLLM : visez au moins 0.32.0. Toute version antérieure reste exposée au lot d'octobre.
• Ghostscript : 10.03.1 ou plus récent — sous cette version, le host est vulnérable à l'évasion de sandbox (CVE-2024-29510).
• Pillow : 12.3.0 ou plus récent, qui rejette l'échantillon EPS bouclé utilisé comme preuve de concept.

Faites ce diagnostic sur le host et dans chaque image Docker qui embarque vLLM. Les deux environnements ont leurs propres versions de Ghostscript et de Pillow.

Étape 2 : mise à jour

pip install --upgrade "vllm>=0.32.0"
pip install --upgrade "pillow>=12.3.0"

# Sur le host (Debian/Ubuntu)
apt-get update && apt-get install --only-upgrade ghostscript

Si vous utilisez une image officielle, repartez d'une image reconstruite après le 28 octobre 2026 — reconstruire par-dessus un cache Docker peut conserver les anciennes couches.

Étape 3 : durcissement, indépendamment de la version

# Authentification systématique — jamais optionnelle
export VLLM_API_KEY="votre-clé-forte"

# Si vous servez un modèle avec des inputs image, vérifiez que
# la liste blanche de formats est active dans votre configuration

Trois règles non négociables :

1. Une clé API sur chaque endpoint, même « interne ». CVE-2026-115917 existe précisément parce que le défaut est permissif.
2. Ghostscript ≥ 10.03.1 sur tout host qui exécute vLLM. Même avec vLLM 0.32.0, un Ghostscript vulnérable est une bombe à retardement pour tout futur bug de pipeline d'images.
3. Un reverse proxy avec authentification et restriction CORS devant tout endpoint partagé entre équipes.

Étape 4 : si vous êtes en 0.30.x

Vous cumulez deux vagues d'advisories. La vague de septembre-octobre (RCE via code_revision, hang via min_tokens, crash cross-tenant via logprobs) a été corrigée en 0.31.0 ; le lot du 20 octobre en 0.32.0. Ne faites pas de mise à jour incrémentale : passez directement à 0.32.0, testez sur un environnement de pré-production — un VPS de labo peu coûteux comme ceux proposés par Hostinger fait parfaitement l'affaire pour valider la montée de version — puis basculez.

Étape 5 : mettez en place une veille

Le projet vLLM publie désormais ses avis sur sa page de sécurité GitHub. Abonnez-vous aux releases et aux advisories, ou branchez un scanner comme Trivy sur vos images. Avec 10 avis publiés entre le 23 septembre et le 20 octobre 2026, attendre la prochaine vague de presse pour réagir n'est plus une stratégie viable.

Ce que ce batch révèle sur la sécurité de l'inférence auto-hébergée

Réponse directe : les serveurs d'inférence sont devenus des applications web complexes, mais leur sécurité n'a pas suivi — et l'auto-hébergement vous rend responsable de combler cet écart.

Trois enseignements se dégagent de ce lot d'octobre 2026.

Premier enseignement : le traitement multimodal est la nouvelle surface d'attaque principale. La CVE la plus grave ne passe pas par le texte, mais par une image. C'est un schéma qui se répète dans l'écosystème : dès qu'un serveur accepte des fichiers binaires d'utilisateurs, il hérite de toutes les failles de tous les décodeurs de la chaîne. vLLM ne fait qu'exposer les failles de Pillow et Ghostscript — mais c'est précisément le rôle d'un serveur d'inférence de contenir ce genre de propagation.

Deuxième enseignement : les défauts permissifs sont le vrai ennemi. CORS wildcard, absence d'authentification par défaut, détection de format sans liste blanche — trois des failles de ce lot viennent de choix de conception « pratiques pour démarrer ». Les frameworks optimisent pour l'onboarding rapide, et la sécurité devient un opt-in que beaucoup oublient d'activer. En 2026, déployer un serveur d'inférence sans clé API devrait être aussi inconcevable que déployer un serveur SSH avec mot de passe root.

Troisième enseignement : le rythme des correctifs impose une hygiène de version. Deux vagues d'advisories en moins d'un mois, huit CVE d'un coup, 12 pages d'avis cumulés. Les projets d'inférence IA évoluent à la vitesse des frameworks web, avec la maturité sécurité d'un projet jeune. Si votre process de mise à jour est trimestriel, vous vivrez toujours deux vagues de failles derrière. La bonne approche pour les équipes qui auto-hébergent des modèles — et notre guide des meilleurs LLM pour coder insiste sur ce point quand on compare les options de déploiement — est de traiter le moteur d'inférence comme une dépendance critique : patch mensuel minimum, veille des advisories, et rollback testé.

Un dernier point d'opinion : la tentation du no-code est réelle pour démocratiser l'accès à ces modèles en interne, et notre sélection des meilleurs outils no-code pour utiliser l'IA en témoigne. Mais chaque couche ajoutée devant un endpoint d'inférence est une couche qui doit être configurée avec la même rigueur. Un outil no-code connecté à un vLLM sans authentification, c'est simplement un nouveau chemin vers CVE-2026-115917.

❌ Erreurs courantes

Erreur 1 : « Mon serveur n'est pas exposé sur internet, donc je ne suis pas concerné »

C'est l'erreur la plus fréquente, et la plus coûteuse. CVE-2026-115917 exploite précisément les serveurs internes via les navigateurs du LAN. CVE-2026-115915 n'exige qu'un accès à l'API — qui, dans une entreprise, signifie souvent des dizaines de personnes et de postes. Un endpoint interne sans authentification est un endpoint public avec une étape de plus.

Erreur 2 : Mettre à jour vLLM sans mettre à jour Ghostscript

Le correctif de vLLM 0.32.0 empêche les octets EPS d'atteindre Ghostscript via le pipeline d'images. Mais si votre host garde un Ghostscript vulnérable à CVE-2024-29510, toute future faille de pipeline — et il y en aura d'autres — réactive le chemin d'exécution de code. Mettez à jour les deux, systématiquement.

Erreur 3 : Reconstruire l'image Docker par-dessus l'ancienne

docker build avec un cache existant peut conserver les couches contenant l'ancien Ghostscript ou l'ancien vLLM. Après une mise à jour de sécurité, repartez d'un docker build --no-cache ou d'une image de base reconstruite, puis vérifiez les versions dans le conteneur, pas seulement sur le host.

Erreur 4 : Confondre « pas de RCE » et « pas grave »

CVE-2026-115916 (crash engine) et les avis medium de DoS ne permettent pas d'exécuter du code, et leur CVSS le reflète. Mais sur une infrastructure GPU qui coûte des milliers d'euros par mois, un déni de service déclenchable par une seule requête est un incident majeur. La disponibilité fait partie de la sécurité.

❓ Questions fréquentes

Faut-il vraiment passer à 0.32.0 si on est déjà en 0.31.0 ?

Oui. La 0.31.0 corrige la vague précédente (RCE via code_revision, hang via min_tokens, crash cross-tenant logprobs), mais pas le lot du 20 octobre 2026. Les huit avis d'octobre — dont les deux High (EPS/Ghostscript et SHM/pickle) — ne sont corrigés qu'en 0.32.0.

Le correctif vLLM suffit-il à neutraliser le problème Ghostscript ?

Il neutralise le chemin d'exploitation connu, en empêchant les octets EPS d'atteindre Ghostscript via le pipeline d'images. Mais la défense en profondeur reste nécessaire : Ghostscript ≥ 10.03.1 sur le host et Pillow ≥ 12.3.0 ferment les couches en amont et en aval si une nouvelle variante apparaît.

Comment vérifier rapidement si mon installation est vulnérable ?

Trois commandes : pip show vllm (vulnérable si < 0.32.0), gs --version sur le host et dans le conteneur (vulnérable si < 10.03.1), et vérifiez que --api-key ou VLLM_API_KEY est bien configuré sur votre serveur. L'ensemble prend moins de cinq minutes.

Le CORS wildcard est-il vraiment exploitable si mon serveur n'a pas d'authentification ?

Oui, et c'est même le pire des cas. N'importe quelle page web visitée depuis un navigateur du LAN peut appeler GET /v1/models et POST /v1/chat/completions sur votre serveur. Avec une clé API configurée, l'attaque est bloquée en l'absence de fuite de clé — ce qui en fait un argument de plus pour l'authentification systématique.

Ces failles concernent-elles aussi les API managées (OpenAI, Anthropic, etc.) ?

Non. Ces CVEs concernent le moteur open source vLLM dans ses déploiements self-hosted. Les fournisseurs managés gèrent leur propre infrastructure et leurs propres patchs. Cela dit, le schéma « input utilisateur → décodeur tiers → RCE » est un risque générique : ce qui change, c'est qui porte la responsabilité du patch.

✅ Conclusion

Huit CVE en une publication, deux chemins d'exécution de code, un crash d'engine à une requête et un CORS ouvert par défaut : le lot d'octobre 2026 de vLLM marque un tournant dans la maturité — et l'exigence — de la sécurité de l'inférence self-hosted. Passez en 0.32.0 cette semaine, mettez Ghostscript et Pillow à niveau, et ajoutez une clé API sur chaque endpoint. Si vous évaluez quels modèles déployer sur cette infrastructure fraîchement patchée, notre comparatif des meilleurs outils IA pour le code vous aidera à choisir la stack adaptée à votre équipe.