vLLM : une seule regex peut figer un worker d'inférence

De quoi s’agit-il ?

Le 6 juillet 2026, un avis de sécurité a été publié pour vLLM, l’un des moteurs open source d’inférence et de service les plus déployés pour les grands modèles de langage. La faille est une vulnérabilité de déni de service dans la fonctionnalité de sorties structurées : le paramètre d’API qui permet à un appelant de contraindre la sortie d’un modèle à respecter une expression régulière transmettait ce motif fourni par l’utilisateur directement au compilateur de grammaire, sans aucune limite de temps ni de complexité. Une seule requête portant un motif malveillant pouvait immobiliser indéfiniment un worker d’inférence. Elle est classée comme une faille de complexité inefficace des expressions régulières (CWE-1333), plus connue sous le nom de ReDoS, et touche toutes les versions antérieures à la 0.24.0, où elle est corrigée.

Ce n’est ni une attaque au niveau du prompt, ni un jailbreak de modèle. C’est un bug d’indisponibilité classique de la couche de service, qui se trouve simplement logé dans une fonctionnalité propre aux LLM — précisément le type de surface qui s’étend à mesure que les équipes intègrent le décodage contraint dans leurs API de production.

Comment ça marche

Les sorties structurées permettent à une application de forcer un modèle à produire un texte conforme à un schéma — JSON, une grammaire, ou une expression régulière brute — en contraignant le décodeur à chaque token. Pour cela, la regex choisie doit être compilée en une machine à états que le sampler consulte.

Dans les versions concernées, cette étape de compilation s’exécutait sans garde-fou. Dans le backend xgrammar, le motif atteignait directement le compilateur de regex. Dans le backend outlines, la validation rejetait certaines constructions structurelles telles que les lookarounds et les backreferences, mais n’effectuait aucune analyse de complexité : un motif bâti sur des quantificateurs imbriqués passait donc tous les contrôles, puis explosait. Certaines formes de regex poussent le compilateur à explorer un nombre exponentiel d’états, de sorte qu’une chaîne courte et d’apparence anodine se traduit par un travail pratiquement illimité. Comme la requête est acceptée sur le réseau sans authentification et que la compilation intervient avant toute génération, un seul appel forgé suffit à bloquer le worker et à priver toutes les requêtes légitimes qui y sont routées. L’impact rapporté ne concerne que la disponibilité — pas d’exécution de code, pas de divulgation de données — avec un vecteur d’attaque réseau et aucun privilège requis. Nous ne reproduisons volontairement aucun motif déclencheur ici ; c’est le mécanisme qui compte, pas une charge prête à l’emploi.

Pourquoi c’est important

vLLM occupe le cœur d’un grand nombre de piles LLM auto-hébergées et d’entreprise, souvent derrière une passerelle interne qui fait confiance à ses appelants. Les sorties structurées sont une manière répandue de rendre les réponses des modèles exploitables par des programmes ; le paramètre vulnérable n’est donc pas un recoin obscur, mais une fonctionnalité que l’on sollicite justement dans les pipelines automatisés à haut débit, là où un blocage passé inaperçu fait le plus de dégâts. Dans un déploiement multi-tenant partagé, un seul locataire capable de définir la regex peut dégrader le service de tous les autres sur le même pool de workers, et un endpoint exposé transforme une requête d’une ligne en panne à bas coût. C’est un rappel utile : la couche de service des LLM hérite de tous les risques ordinaires d’un service web en plus des risques propres aux modèles. Des faiblesses de disponibilité voisines dans le même moteur — d’un bug d’épuisement mémoire via l’upload audio à la surface d’attaque plus large de la couche de service — pointent vers la même leçon.

Défenses

Mettez vLLM à niveau vers la 0.24.0 ou une version ultérieure. C’est le correctif principal et complet : le patch ajoute une étape de compilation bornée, de sorte qu’un motif hostile échoue rapidement au lieu de bloquer. L’avis documente aussi un contrôle de délai de compilation (VLLM_REGEX_COMPILATION_TIMEOUT_S, fixé par défaut à cinq secondes) qui lève une erreur plutôt que de bloquer indéfiniment, vous donnant une valeur à journaliser et sur laquelle alerter.

Au-delà du correctif, traitez le paramètre regex comme une entrée non fiable. Si votre application n’a pas besoin de regex fournies par l’appelant, désactivez ou codez en dur le motif des sorties structurées plutôt que de laisser passer des valeurs utilisateur. Là où vous devez les accepter, validez la longueur et la complexité du motif avant compilation et rejetez les quantificateurs imbriqués. N’exposez pas l’endpoint d’inférence directement : exigez une authentification et appliquez des limites de débit par appelant afin qu’un client seul ne puisse monopoliser les workers.

Pour la détection, surveillez les workers d’inférence qui cessent de répondre ou dont le CPU s’envole pendant une compilation, et surveillez les erreurs de délai de compilation une fois le correctif en place. Les outils système habituels — top/htop pour repérer un worker bloqué, un traçage du processus suspect pour voir s’il est coincé dans la compilation de regex — révéleront une tentative en cours.

Statut

Élément	Détail
Concerné	vLLM, toutes versions antérieures à 0.24.0
Corrigé dans	vLLM 0.24.0 (PR #45118)
Faiblesse	CWE-1333, complexité inefficace des expressions régulières (ReDoS)
Impact	Déni de service — disponibilité uniquement ; non authentifié, réseau, aucun privilège
Gravité	CVSS 4.0 8.7 (élevée, CNA) / CVSS 3.1 7.5 (élevée, NVD) ; note du site : moyenne
Référence	CVE-2026-55574 (publié le 2026-07-06) ; avis GHSA-rwxx-mrjm-wc2m