GitHub a publié GHSA-48jh-3gj7-fg8v à 21:37:00 UTC le 4 septembre — CVE-2026-73556, CVSS 5.3, contre vLLM, le serveur d’inférence open source le plus largement déployé. Dans les flux, il apparaît comme un nouveau bug de déni de service. Il s’agit du même bug que le projet avait corrigé en juillet, qui a survécu dans le chemin de code que le correctif n’avait pas touché.
Le chemin jumeau
L’avis est explicite : « The fix for GHSA-rwxx-mrjm-wc2m … wrapped the regex compile in the xgrammar and outlines backends with compile_regex_with_timeout (and, for outlines, validate_regex_is_buildable). The lm-format-enforcer backend was left unguarded: it compiles the attacker-supplied regex with no timeout and no buildability check. » Les trois backends passent par la même construction DFA interegular ; deux sont bornés et un ne l’est pas.
La mesure
L’avis publie ses propres timings : la regex de base '[0-9]{3}' se compile en 0.0002 s ; la regex de l’attaquant '(a{1,300}){300}' n’a pas terminé en 20 s, « one core pegged at 100% in interegular FSM construction ». Comme la compilation de la grammaire s’exécute à l’intérieur du chemin de sortie structurée du moteur, la requête ne revient jamais et les requêtes concurrentes se retrouvent bloquées derrière elle — un déni de service au niveau du worker. L’avis note que la même requête envoyée au backend outlines renvoie une erreur propre.
Ce que le cadrage reçu présente mal
Deux choses. Il s’agit d’un échec de complétude du correctif, pas d’une nouvelle classe d’attaque — le fait intéressant est qu’un correctif de sécurité a atterri dans deux des trois points d’appel frères et que personne ne l’a remarqué pendant six semaines. Et « affected versions < 0.26.0 » se lit comme une exposition actuelle : 0.26.0 a été publié le 27 juillet et la version actuelle est 0.28.0, donc la divulgation intervient 39 jours après le correctif. Toute personne suivant sa version de vLLM n’a jamais été exposée après juillet ; toute personne figée en dessous l’a été, sans le savoir, depuis.
La condition préalable qui n’en est guère une
L’avis indique que « vLLM ships with no authentication by default ». L’attaque consiste en un unique POST vers /v1/completions avec une regex de sortie structurée — aucun identifiant, aucun accès au modèle au-delà du point de terminaison, aucune configuration spéciale si ce n’est la sélection du backend lm-format-enforcer. La sortie structurée est la fonctionnalité que la plupart des déploiements de production activent, car c’est ainsi que les réponses JSON deviennent fiables.