CISA inscrit GPUStack au catalogue KEV : un attaquant non authentifié prend le contrôle d’un cluster GPU d’IA

9 novembre 2026. La CISA ajoute quatre failles à son catalogue KEV (Known Exploited Vulnerabilities). CVSS 9.8. C’est le score de la plus sévère d’entre elles : une faille d’authentification dans GPUStack, un gestionnaire open source de clusters GPU pour l’inférence de modèles. 12 novembre. C’est l’échéance de correction imposée aux agences fédérales américaines. Pourquoi c’est important : pour la première fois, une infrastructure d’IA auto-hébergée entre au catalogue KEV, et la faille permet à un attaquant non authentifié de devenir administrateur d’un cluster — jusqu’à en extraire les secrets cloud.

Ce qu’est le catalogue KEV, et pourquoi l’entrée compte

Le catalogue KEV n’est pas une liste de failles graves : c’est une liste de failles exploitées. La CISA n’y ajoute une CVE que lorsqu’elle dispose de preuves qu’un acteur s’en sert en ce moment. Un score CVSS élevé ne suffit pas — il faut une exploitation observée dans la nature.

Le lot du 9 novembre rassemble quatre produits qui n’ont rien en commun, sinon ce signal d’exploitation :

• GPUStack — CVE-2026-102895, authentification incorrecte, versions antérieures à 2.2.0 ;
• SignalWire FreeSWITCH — CVE-2026-116779, injection de code, versions antérieures à 1.11.3 ;
• OpenBSD OpenSSH — CVE-2026-123158, contournement d’authentification par mot de passe, sshd avant 10.6p2 sur musl sans PAM ;
• IBM Aspera Faspex — CVE-2026-123218, autorisation incorrecte, de 5.0.0 à 5.0.19.

Deux de ces libellés parlent explicitement d’authentification ou d’autorisation. C’est un détail de tri important : les failles de contrôle d’accès offrent un chemin d’entrée scriptable et propre, et laissent moins de traces qu’un crash ou une corruption mémoire.

GPUStack : la porte d’administration ouverte

GPUStack est un gestionnaire de clusters GPU pour le serving de modèles et le provisionnement d’instances GPU, distribué sous licence Apache 2.0. Sa promesse est simple : transformer un parc de cartes graphiques en plateforme d’inférence comparable à un petit vLLM centralisé. C’est précisément cette position qui rend la faille coûteuse : un gestionnaire de GPU détient les identifiants des clouds et des workers qu’il orchestre.

CVE-2026-102895 est une faille d’authentification incorrecte. L’impact rapporté ressemble à une prise de contrôle totale : un attaquant non authentifié peut atteindre les fonctions administratives, modifier les utilisateurs et les modèles, créer des clés d’API administrateur et extraire les secrets des workers et des fournisseurs cloud. L’exécution de code passe par l’endpoint POST /v2/inference-backends/from-yaml, qui accepte une définition d’inférence au format YAML. Des chercheurs rapportent une exploitation observée contre un déploiement en 2.1.1, le schéma classique des attaquants qui ciblent les installations en retard de quelques versions.

Le correctif est la version 2.2.0. Mais s’arrêter là serait une erreur : les releases GitHub du projet listent v2.3.0 comme dernière version stable au 9 novembre, et une base de vulnérabilités datée du 4 novembre signale une seconde faille d’autorisation, CVE-2026-103002, couvrant les versions 2.2.0 à 2.2.2. La lecture prudente tient en une phrase : exécuter la dernière stable 2.3.0, pas s’arrêter à 2.2.0.

Le piège qui survit au correctif : les secrets

La partie la plus durable de cette faille n’est pas le code, mais les identifiants. Un gestionnaire de GPU conserve les jetons des clouds et des workers qu’il pilote. Si un attaquant a créé une clé d’API administrateur ou copié un jeton cloud avant la mise à jour, installer 2.2.0 ferme la porte sans invalider les clés volées.

La parade est donc double : mettre à jour, puis révoquer. Les équipes doivent faire tourner les identifiants des workers et des fournisseurs cloud et révoquer toute clé d’API dont elles ne peuvent pas rendre compte. C’est la différence entre corriger une vulnérabilité et clore un incident.

Les trois autres entrées, en une ligne chacune

FreeSWITCH (CVE-2026-116779) touche un moteur de téléphonie qui accepte par conception des messages venus d’inconnus : une injection de code via un message SIP fabriqué peut offrir à la fois un point d’ancrage et une plateforme de fraude téléphonique. OpenSSH (CVE-2026-123158) est la plus étroite des quatre — seuls les systèmes musl sans PAM, typiquement des conteneurs minimalistes et des appliances, sont exposés, et Portable OpenSSH 10.6p2 corrigeait déjà la faille depuis le 5 novembre (nous l’avons détaillée dans notre analyse du contournement sshole). IBM Aspera Faspex (CVE-2026-123218) est un serveur de transfert de fichiers volumineux dont l’autorisation incorrecte se corrige par l’image conteneur 5.0.19 PL1, sans contournement documenté.

Ce qui unit ces quatre entrées, c’est le calendrier : ajoutées le 9 novembre, à corriger pour le 12 novembre côté fédéral. Les équipes qui ont vidé leur liste un vendredi se retrouvent avec une nouvelle liste le lundi.

Comment vérifier son exposition en une minute

Le tri est rapide, produit par produit. Pour GPUStack, comparez simplement votre version installée à la 2.3.0 — l’interface d’administration ou la page des releases suffisent, inutile de chercher une commande dédiée. Pour OpenSSH, la faille ne touche que les builds musl sans PAM, et deux commandes règlent la question :

sshd -V 2>&1 | head -n 1
ldd "$(command -v sshd)" | grep -Ei 'musl|libpam'

Si sshd -V renvoie une version antérieure à 10.6p2 et que ldd montre musl sans libpam, vous êtes dans le périmètre : passez à 10.6p2 ou plus récent. Pour FreeSWITCH et Aspera Faspex, la règle est identique — confirmer la version déployée contre le seuil de correction, puis planifier le patch.

Pourquoi c’est un signal de fond

L’entrée de GPUStack au KEV marque un changement de nature. L’infrastructure d’IA auto-hébergée — clusters GPU, orchestrateurs d’inférence, registres de modèles — est devenue une cible à part entière, au même titre que les VPN, les pare-feux ou les serveurs de messagerie. La raison est mécanique : ces outils concentrent des GPU coûteux et des identifiants cloud dans un seul point d’administration, souvent exposé par commodité.

Le schéma d’attaque est celui d’un cryptojacking évolué : un attaquant qui contrôle un cluster GPU peut miner, exfiltrer des secrets, ou reconfigurer l’inférence pour servir ses propres modèles. Le coût n’est plus seulement une facture d’électricité — c’est la compromission du compte cloud qui finance le cluster.

Le signal dépasse GPUStack. Les orchestrateurs d’inférence, les registres de modèles et les consoles de gestion de GPU partagent le même profil : un point d’administration unique, des secrets cloud intégrés, et une exposition fréquente sur Internet pour simplifier l’accès des équipes. C’est exactement le profil que la CISA surveille désormais au même titre que les appliances réseau.

Verdict

Si vous exécutez GPUStack en version antérieure à 2.2.0, mettez à jour vers la 2.3.0 immédiatement, puis faites tourner les identifiants des workers et des fournisseurs cloud et révoquez toute clé d’API inconnue — dans cet ordre, la mise à jour d’abord, la révocation ensuite, jamais l’inverse. La faille est exploitée dans la nature, ce qui change la gravité : vous ne corrigez pas une menace théorique, vous fermez une porte qu’un acteur essaie déjà d’ouvrir. Pour les trois autres entrées, appliquez le correctif correspondant (FreeSWITCH au-delà de 1.11.2, OpenSSH 10.6p2, Aspera Faspex 5.0.19 PL1) et traitez le 12 novembre comme votre propre échéance, pas comme une contrainte réservée aux agences fédérales.

Références

• CISA — Known Exploited Vulnerabilities Catalog (consultée le 10 novembre 2026)
• Shattered — « CISA Adds 4 Exploited Flaws, Feds Due Nov. 12 » (mis à jour le 10 novembre 2026)
• GPUStack — releases GitHub (consultées le 10 novembre 2026)
• ETTAYEB — notre analyse du contournement sshole d’OpenSSH (CVE-2026-123158)