Une vulnérabilité récemment découverte de corruption de mémoire dans vLLM pourrait permettre à des attaquants de faire tomber des serveurs ou d’exécuter du code arbitraire en envoyant des embeddings de prompts malveillants à l’API Completions.
La faille touche les versions 0.10.2 et ultérieures de vLLM, exposant immédiatement les déploiements d’IA en production.
« La vulnérabilité permet à tout utilisateur ayant accès à l’API de provoquer potentiellement un déni de service et une exécution de code à distance dans le processus du serveur vLLM », ont déclaré les chercheurs de Wiz Security.
Comprendre la cause profonde de la faille vLLM
La vulnérabilité (CVE-2025-62164) découle de la manière dont vLLM traite les embeddings de prompts fournis par l’utilisateur, une fonctionnalité destinée à permettre aux applications avancées de transmettre directement au modèle des vecteurs précalculés.
Lorsqu’un client envoie un embedding à l’API Completions, vLLM tente de reconstituer le tenseur en désérialisant la charge utile encodée en Base64 à l’aide de la fonction torch.load() de PyTorch.
Le problème se situe dans entrypoints/renderer.py, où vLLM décode l’embedding encodé en Base64 et le désérialise à l’aide de torch.load().
Après avoir chargé le tenseur, le serveur le convertit immédiatement en tenseur dense avec to_dense() — sans effectuer le moindre contrôle d’intégrité ou de sécurité.
Dans cette partie du code, vLLM prend simplement l’embedding fourni par l’utilisateur, le charge via torch.load(io.BytesIO(pybase64.b64decode(embed, validate=True)), weights_only=True, map_location=torch.device(“cpu”)), puis exécute tensor = tensor.to_dense() sans aucune validation intermédiaire.
Comme vLLM considère à ce stade que le tenseur est valide et sûr, toute charge utile conçue à des fins malveillantes peut franchir l’étape de désérialisation et provoquer une corruption de mémoire lors de la densification, permettant un déni de service ou, potentiellement, l’exécution de code à distance.
La modification de PyTorch qui a ouvert la voie
Dans PyTorch 2.8.0, le framework a désactivé par défaut les contrôles d’intégrité des tenseurs creux, supprimant les garde-fous qui vérifiaient auparavant les limites des index, la cohérence de la forme du tenseur et les invariants internes requis avant l’appel à to_dense().
Ces contrôles doivent désormais être réactivés explicitement à l’aide de torch.sparse.check_sparse_tensor_invariants, mais vLLM n’implémente pas cette protection.
Un attaquant peut donc créer un tenseur creux malformé dont les index internes pointent en dehors des plages mémoire attendues.
PyTorch chargera tout de même le tenseur avec succès, mais lorsque vLLM appellera ensuite to_dense(), le framework tentera de matérialiser entièrement le tenseur malformé en mémoire dense, provoquant une écriture hors limites et permettant une éventuelle corruption de mémoire.
Ce que les attaquants peuvent faire avec cette faille vLLM
Selon la manière dont la charge utile malveillante est conçue, l’écriture hors limites peut avoir plusieurs conséquences graves.
Elle peut faire tomber le serveur et provoquer un déni de service (DoS) si la mémoire critique d’exécution est corrompue.
Dans les cas les plus avancés, un attaquant pourrait exécuter du code arbitraire en écrasant des zones mémoire qui influencent le flux de contrôle.
Cela ouvre également la voie à une compromission latérale au sein de la pile d’IA, puisque vLLM fonctionne souvent aux côtés de composants sensibles tels que les GPU, les poids des modèles, les journaux ou les données propriétaires.
Comme le chemin de désérialisation vulnérable est exposé par l’API Completions accessible au public, l’attaquant n’a besoin ni de privilèges élevés ni d’un accès préalable — il lui suffit de pouvoir envoyer des charges utiles d’embeddings au serveur.
Au cœur de la faille de désérialisation
Cette chaîne d’exploitation relève de la désérialisation non sécurisée, dans laquelle une entrée non fiable est directement reconstruite en objets en mémoire. Dans le cas de vLLM, le risque est amplifié parce que :
- La désérialisation des tenseurs est complexe et gourmande en mémoire.
- La charge utile de l’embedding ne passe par aucune couche de validation.
- La bibliothèque sous-jacente (PyTorch) autorise silencieusement les données malformées.
En bref, le système prend des octets contrôlés par l’attaquant, les reconstruit en tenseur creux, puis demande à PyTorch de développer ce tenseur en mémoire dense — le tout sans vérifier que le tenseur respecte les invariants requis.
Principales mesures pour atténuer la vulnérabilité de vLLM
Compte tenu de la gravité de la faille de désérialisation de vLLM, les équipes de sécurité doivent adopter une stratégie d’atténuation à plusieurs niveaux afin de réduire le risque de compromission des serveurs.
- Mettez à jour vers la version corrigée de vLLM et appliquez les contrôles d’intégrité des tenseurs creux de PyTorch pour empêcher toute désérialisation non sécurisée.
- Restreignez et authentifiez l’accès à la Completions API en supprimant son exposition publique, en imposant une authentification forte et en appliquant une limitation du débit.
- Validez et filtrez tous les embeddings de prompts via une passerelle d’API, un WAF ou un middleware afin de bloquer les tenseurs malformés ou non fiables avant qu’ils n’atteignent vLLM.
- Isolez vLLM dans des environnements renforcés tels que des conteneurs ou des machines virtuelles dédiés, en appliquant le principe du moindre privilège, la segmentation et des comptes de service non privilégiés.
- Activez la surveillance et la journalisation des indicateurs d’exploitation, notamment les plantages, les embeddings malformés, les échecs de désérialisation et les comportements anormaux lors de l’inférence.
- Renforcez la sécurité de l’exécution et de l’infrastructure en appliquant l’ASLR, DEP/NX, la segmentation réseau, des contrôles d’accès et des tests de sécurité réguliers tels que le fuzzing et les audits des dépendances.
Les défenses en profondeur, la surveillance continue et les principes de sécurité dès la conception contribuent à garantir que les menaces futures seront détectées plus tôt et contenues plus efficacement.
L’infrastructure d’IA devient une cible de choix
Cette vulnérabilité met en évidence une tendance croissante de la sécurité de l’IA : la surface d’attaque ne comprend pas seulement le modèle — elle englobe aussi le code d’intégration, les moteurs d’inférence, les bibliothèques de sérialisation et les pipelines de données qui l’entourent.
À mesure que les organisations adoptent davantage de capacités alimentées par des LLM, les faiblesses des frameworks de support tels que vLLM et PyTorch, ainsi que des API de mise à disposition des modèles, deviennent des cibles de plus en plus attrayantes.
L’incident souligne également la manière dont de subtils changements en amont — en l’occurrence, la désactivation des contrôles d’intégrité par PyTorch — peuvent créer des failles de sécurité qui se répercutent dans tout l’écosystème de l’IA.
À mesure que l’infrastructure d’IA devient plus modulaire et interconnectée, même de légères failles de désérialisation peuvent dégénérer en compromission complète si les organisations n’appliquent pas les correctifs et n’imposent pas une validation stricte des entrées.