CVE-2025-62164 est une vulnérabilité de haute sévérité dans le logiciel vLLMl'un des moteurs d'inférence LLM open-source les plus largement déployés. Le problème réside dans le moteur d'inférence API Complétions et est déclenché lorsque le serveur traite les incrustations d'invite fournies par l'utilisateur. Dans les versions concernées (0.10.2 jusqu'à la version 0.11.1 incluse), vLLM désérialise les tenseurs à l'aide de torch.load() sans validation solide. Un tenseur clair peut se faufiler et provoquer une erreur d'interprétation. écriture hors limites pendant la densificationqui fait planter le travailleur de manière fiable et peut conduire à l'exécution de code à distance dans les bonnes conditions. Le projet a fourni un correctif dans vLLM 0.11.1. (NVD)

Deux choses font que ce CVE est différent des bugs habituels de la pile d'IA. Premièrement, il s'agit d'un défaut du plan de donnéesEn effet, il ne s'agit pas d'une interface d'administration ou d'une mauvaise configuration, mais d'un chemin d'exploitation accessible par le même point de terminaison d'inférence que celui utilisé par vos utilisateurs pour les complétions. Deuxièmement, il se trouve à l'intersection exacte de désérialisation non sécurisée et dérive du comportement en amontUne combinaison qui ne cesse d'apparaître au fur et à mesure que l'infrastructure du LLM se développe.

Où se situe vLLM dans la pile - et pourquoi ce positionnement amplifie les risques

vLLM est effectivement une couche d'inférence à débit optimisé. Les équipes la déploient en tant qu'API SaaS publique, derrière une passerelle d'entreprise ou en tant que backend de service pour des systèmes d'agents multi-locataires. Dans toutes ces configurations, vLLM est proche d'Internet et des ressources GPU. Cela ressemble à de l'ingénierie de performance, mais cela signifie également que la vLLM est proche de l'Internet et des ressources GPU. les appelants d'API à faible privilège peuvent atteindre des chemins de code privilégiés. (wiz.io)

Le rayon d'action n'est donc pas subtil. Un seul point d'extrémité susceptible de s'effondrer peut provoquer une pénurie de GPU, une accumulation de files d'attente, une saturation de l'autoscaler et des incidents bruyants avec les voisins. Si l'exploitation se stabilise en RCE, la flotte d'inférence devient un point d'appui légitime pour l'intrusion dans la chaîne d'approvisionnement.

La vulnérabilité en un paragraphe

Dans les versions vulnérables de vLLM, le point de terminaison "Completions" permet aux clients de transmettre les informations suivantes les encastrements rapides au lieu du texte brut. vLLM reconstruit ces tenseurs par le biais de torch.load() sans contrôle suffisant de l'intégrité, du type ou de la structure. Depuis le PyTorch 2.8.0 désactive par défaut les contrôles d'intégrité des tenseurs sparseun tenseur clair malveillant peut contourner les protections internes contre les limites et déclencher une alarme. écriture mémoire hors limites lorsque to_dense() est appelé. Le résultat immédiat et reproductible est DoS à distance (plantage du travailleur). Avec une disposition et un contrôle favorables de la mémoire, la même primitive pourrait plausiblement être transformée en RCE sur l'hôte. (NVD)

Anatomie des causes profondes : comment le "passage pratique de l'intégration" s'est transformé en corruption de la mémoire

Un puits de désérialisation sur un point final public

torch.load() est puissant de par sa conception. Il est destiné à restaurer les tenseurs et les graphes d'objets à partir de sources fiables (points de contrôle, pipelines internes). Dans le cas de vLLM, il est utilisé sur un champ qui peut être rempli par un appelant API. Cela déplace la frontière de confiance de "artefact de modèle interne" à "entrée internet non fiable", qui est historiquement là où la désérialisation non sécurisée explose. (NVD)

Même si ce problème se manifeste par une corruption de la mémoire plutôt que par une chaîne pickle-RCE classique, l'erreur sous-jacente est la même : traiter une structure binaire complexe comme s'il s'agissait d'un simple paramètre de requête.

Le changement de comportement de PyTorch 2.8.0 a été l'étincelle

L'avis vLLM et le NVD épinglent tous deux l'escalade sur une modification de PyTorch : les vérifications de l'intégrité des tenseurs sparse sont désormais désactivées par défaut. Auparavant, les tenseurs sparse malformés étaient plus susceptibles d'être rejetés avant que le chemin du code n'atteigne la densification. Avec les contrôles désactivés, le manque de pré-validation de vLLM est devenu exploitable de manière cohérente. (NVD)

Il s'agit d'un modèle mental utile pour la sécurité des infrastructures d'IA : les défauts en amont peuvent silencieusement transformer un état "peu sûr mais dormant" en un état "peu sûr et susceptible d'être armé".

La réalité de l'impact : Le DoS est garanti, le RCE est un plafond

Tous les rapports publics s'accordent à dire que le déni de service à distance est fiable. Une seule requête malformée peut tuer un travailleur ; des requêtes répétées peuvent rendre une flotte instable. (ZeroPath)

Le CRE est décrit comme suit potentiel pour de bonnes raisons. La corruption de la mémoire fournit une voie d'accès, mais l'armement dépend du comportement de l'allocateur, des drapeaux de renforcement, des limites du conteneur et du degré de contrôle de l'attaquant sur la région corrompue. Il y a pas de liste CISA KEV et aucune chaîne d'exploitation largement confirmée dans la nature au 25 novembre 2025, mais il serait erroné de considérer la corruption de la mémoire du plan de données comme un "déni de service" uniquement. (wiz.io)

Versions concernées et état des corrections

(NVD)

Qui doit paniquer en premier ? Les modèles de menace qui comptent

Si vous voulez un objectif pratique de hiérarchisation, réfléchissez à l'endroit où les "embeddings" peuvent pénétrer dans votre système.

Les points d'extrémité vLLM publics constituent le cas évident à haut risque. Même si les appelants ont besoin d'une clé API, la barre est basse : un utilisateur normal disposant d'un accès de base peut suffire à faire planter vos travailleurs. (wiz.io)

Les plates-formes multi-locataires de "LLM as a Service" viendront ensuite. Le risque est de voir les "embeddings" s'écouler dans le monde entier. indirectement - par l'intermédiaire de chaînes d'outils, de plugins, de cadres d'agents ou de services en amont qui optimisent l'intégration des données. Plus vous acceptez de charges utiles non textuelles, plus votre frontière de confiance devient compliquée.

Enfin, ne négligez pas les démonstrations communautaires et les déploiements éducatifs. Ils sont souvent non authentifiés, insuffisamment surveillés et exposés longtemps après que leur propriétaire en a oublié l'existence.

Moyens sûrs de confirmer l'exposition (sans sondages risqués)

Le triage le plus rapide est basé sur la version.

python -c "import vllm ; print(vllm.__version__)"
# affecté si 0.10.2 <= version < 0.11.1

(NVD)

D'un point de vue opérationnel, il convient de rechercher un modèle de les défaillances des travailleurs ou les redémarrages brutaux liées à des demandes d'achèvement inhabituellement importantes ou structurellement bizarres. Dans la pratique, les pics de crash apparaissent en premier ; l'exploitation sophistiquée (si elle arrive un jour) arrive plus tard. (ZeroPath)

Un contrôle canari inoffensif - complétions standard, pas de transfert d'incorporation - est utile pour établir une base de stabilité autour des correctifs :

importer des requêtes, json, temps

HOST = "https:///v1/complétions"
headers = {"Authorization" : "Bearer "}

payload = {
    "model" : "votre-nom-de-modèle",
    "prompt" : "health check",
    "max_tokens" : 4
}

for i in range(5) :
    r = requests.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    print(i, r.status_code, r.text[:160])
    time.sleep(1)

Patch rapide, puis durcissement du plan de données

La véritable solution consiste simplement à passer à la version vLLM 0.11.1 ou plus récent. Tout le reste n'est qu'un pis-aller. (NVD)

Après cela, traitez les "entrées d'inférence binaire" comme des puits à haut risque. Si votre produit a réellement besoin d'un passage par l'intégration, il faut l'encadrer par une validation stricte du schéma : appliquez les types de tenseurs attendus, les formes, les tailles maximales, et interdisez les formats épars à moins que vous ne les preniez explicitement en charge. Même une liste d'autorisation stupide bloque la classe spécifique de structures malformées sur laquelle s'appuie cette CVE. (wiz.io)

Du côté de l'infrastructure, verrouillez le rayon d'action. Les travailleurs vLLM doivent fonctionner avec le moins de privilèges possible, des systèmes de fichiers en lecture seule lorsque c'est possible, aucun montage d'hôte sensible et des profils seccomp/AppArmor de conteneur. Si quelqu'un enchaîne une corruption de la mémoire à une exécution de code, vous voulez qu'il soit piégé dans une boîte qui ne peut pas atteindre les secrets ou les chemins latéraux.

Pourquoi CVE-2025-62164 est-il important pour la sécurité de l'IA en tant que discipline ?

Cet incident illustre parfaitement la façon dont la sécurité de l'IA s'éloigne des procédures classiques de l'application web.

La nouvelle frontière est les plans de données du service-modèleLes tenseurs, les embeddings, les blobs multimodaux et les artefacts sérialisés qui circulent dans les API parce qu'ils sont rapides et pratiques. Ils sont également structurellement riches et fragiles - parfaits pour les bugs de corruption si vous désérialisez sans paranoïa.

Il s'agit également de rappeler que la surface de risque d'une pile de LLM est de compositionnel. vLLM n'a pas "inventé" l'insécurité des tenseurs sparse ; une valeur par défaut de PyTorch a changé, et une couche de validation manquante en aval a transformé ce changement en CVE. L'ingénierie de l'inférence a désormais besoin du même niveau d'examen des dépendances que les équipes du noyau considèrent comme acquis.

Validation contrôlée lorsque les PoC sont compliqués ou tardifs

Les CVE de l'infrastructure d'IA arrivent souvent avant les PoC publics stables, ou avec des PoC qui sont trop risqués pour être dirigés vers des clusters de production. L'approche défendable consiste à industrialiser une boucle plus sûre : renseignements faisant autorité → hypothèse → validation en laboratoire → preuves vérifiables.

Dans les flux de travail agentiques de type Penligent, vous pouvez demander à des agents d'ingérer l'avis vLLM et l'enregistrement NVD, de dériver les conditions d'exposition exactes (versions, chemins d'intégration, hypothèses PyTorch) et de générer un avis vLLM. plan de validation à risque minimal que vous n'exécutez que dans une réplique isolée. Vous obtiendrez ainsi de véritables preuves - empreintes de version, signatures de crash, deltas avant/après correctifs - sans avoir à jouer avec vos GPU de prod. (NVD)

Tout aussi important, le fait de rapporter des preuves d'abord permet d'expliquer plus facilement l'urgence à la direction des opérations. L'affirmation "Nous avons mis en place un correctif parce qu'un blog l'a dit" ne survit pas à l'examen de l'incident. "CVE-2025-62164 PoC : Bug dans le plan de données des complétions de vLLM qui transforme les embeddings en surface d'attaque.