Les routes audio de vLLM chargent tout l'upload avant de vérifier sa taille

En bref La sécurité des LLM parle surtout de prompts. Ici, il s’agit de tuyauterie. Une vulnérabilité divulguée le 6 juillet 2026 dans les endpoints audio de vLLM montre que le serveur charge tout le fichier audio en mémoire avant de vérifier la limite de taille configurée — un appelant peut donc envoyer un upload surdimensionné et forcer le processus à allouer une mémoire proportionnelle au fichier, créant une pression mémoire ou tuant le processus. Sont concernées les versions 0.22.0–0.23.x ; le correctif est dans la 0.24.0. Ceci est une analyse de classe de faille, pas un exploit.

De quoi s’agit-il ?

vLLM est l’un des moteurs les plus déployés pour servir des grands modèles de langage. Lorsqu’il sert un modèle vocal, il expose des routes audio compatibles OpenAI — /v1/audio/transcriptions et /v1/audio/translations — qui acceptent un fichier audio envoyé sous forme de requête multipart.

La faille divulguée, publiée dans l’écosystème CVE le 6 juillet 2026 et documentée dans l’avis de sécurité GitHub de vLLM (GHSA-v82g-2437-67m2), est une erreur d’ordonnancement dans le traitement de ces uploads. vLLM propose une limite documentée pour les uploads audio — VLLM_MAX_AUDIO_CLIP_FILESIZE_MB, à 25 Mo par défaut — mais cette vérification intervient plus tard, à l’étape de prétraitement speech-to-text, après que le fichier a déjà été chargé en mémoire. Le score est de CVSS 6.5 (moyen), avec un impact limité à la disponibilité. Ni exécution de code, ni fuite de données : le gain pour l’attaquant est un déni de service.

Comment ça marche

Le mécanisme est un cas d’école de consommation de ressources incontrôlée (CWE-400 / CWE-770), et il n’y a rien d’exotique à reproduire — l’important est la séquence, pas un payload.

Cycle de vie de la requête sur les routes audio (versions vulnérables)
----------------------------------------------------------------------
1. Le client envoie un upload audio multipart vers /v1/audio/transcriptions
2. Le handler appelle request.file.read()  --> TOUT le fichier chargé en RAM
3. Le prétraitement speech-to-text s'exécute
4. Seulement maintenant : comparaison avec VLLM_MAX_AUDIO_CLIP_FILESIZE_MB
5. La requête surdimensionnée est enfin rejetée -- mais la mémoire est déjà dépensée

Parce que tout le corps est chargé à l’étape 2, la mémoire allouée par vLLM dépend de la taille d’upload choisie par l’attaquant, et non de la politique de 25 Mo que l’opérateur croit protectrice. Un seul upload multipart surdimensionné — ou quelques-uns en parallèle — gonfle la mémoire résidente avant que la requête soit rejetée. Selon les limites de ressources du déploiement, cela se traduit par une latence dégradée pour les requêtes légitimes, une pression mémoire critique, ou l’arrêt pur et simple du processus. L’avis précise que ces routes nécessitent un certain niveau d’accès, et que la faille est atteignable à distance sur le réseau avec une faible complexité.

Pourquoi c’est important

Les serveurs d’inférence sont de plus en plus traités comme de simples services web, mais ils portent un coût par requête inhabituellement lourd : GPU, modèles résidents volumineux, pipelines de prétraitement média. Cela en fait une cible facile pour les attaques par épuisement de ressources, dont le but n’est pas de voler mais de faire tomber un service à moindre coût. Une limite de taille documentée mais appliquée après l’allocation coûteuse est un échec courant et facile à manquer — le garde-fou existe, il s’exécute simplement une étape trop tard.

La leçon plus large : une entrée non fiable dans une pile LLM doit être bornée avant d’être matérialisée, la même discipline que pour n’importe quel endpoint d’upload de fichier. Le cadrage « IA » ne change pas les fondamentaux : une route audio est une route d’upload de fichier, et les routes d’upload qui lisent d’abord et valident ensuite mènent au déni de service par épuisement mémoire.

Défenses

1. Mettez à jour vers vLLM 0.24.0 ou ultérieure. Le correctif (pull request #45510) déplace la vérification pour que la limite de taille soit appliquée avant le chargement complet de l’upload. Vérifiez votre version avec pip show vllm.
2. Imposez une limite de taille de corps de requête en amont. Placez une passerelle ou un reverse proxy authentifié devant vLLM et plafonnez-y la taille des uploads (par exemple client_max_body_size sous nginx), afin que les requêtes surdimensionnées soient rejetées avant d’atteindre le processus d’inférence. Cela protège toute la classe, pas seulement cette route.
3. N’exposez pas les endpoints vLLM bruts à des appelants non fiables. Par défaut, vLLM a une authentification faible ou nulle ; restreignez l’accès entrant et exigez une authentification sur les routes audio.
4. Bornez le processus, pas seulement la politique. Faites tourner le service sous des limites mémoire container/cgroup avec redémarrage automatique, pour qu’un pic mémoire se dégrade et se rétablisse au lieu de tuer l’hôte. Ajoutez du rate limiting et des quotas par client sur les endpoints d’upload.
5. Validez la taille avant l’allocation, partout. Traitez le « tout lire, puis vérifier » comme un anti-pattern dans vos propres outils — streamez et rejetez tôt sur tout endpoint acceptant des uploads non fiables.

Statut

Élément	Référence	Date	Notes
Avis éditeur	GitHub (GHSA-v82g-2437-67m2) — CVE-2026-55646	2026-07-06	Les routes audio chargent tout l’upload avant la vérif. de taille
Classe de faille	CWE-400 / CWE-770	—	Consommation de ressources incontrôlée / pas de limite d’allocation
Sévérité	CVSS 3.1 base 6.5 (moyen)	—	Réseau, faible complexité ; impact sur la seule disponibilité
Versions affectées	vLLM	0.22.0 → 0.23.x	Déploiements servant des modèles speech-to-text
Version corrigée	vLLM 0.24.0	2026	Limite de taille appliquée avant le chargement (PR #45510)

Le bon cadrage n’est pas « encore une CVE vLLM ». C’est qu’un serveur d’inférence est un service web aux requêtes coûteuses, et que la plus vieille règle des uploads non fiables tient toujours : bornez l’entrée avant de dépenser de la mémoire dessus.