Rapport CTI technique du 10 novembre 2026
Résumé exécutif
GPUStack est un gestionnaire de cluster GPU open source pour le serving de modèles et l'approvisionnement d'instances GPU. Sa version antérieure à 2.2.0 contient une vulnérabilité d'authentification impropre, CVE-2026-102895, cotée CVSS 9.8 (critique). La fonction get_current_user du module gpustack/api/auth.py promeut automatiquement tout appelant perçu comme venant de 127.0.0.1 au compte administrateur intégré lorsque force_auth_localhost vaut false, la valeur par défaut. Un attaquant distant peut faire apparaître cette provenance loopback via un reverse proxy sur le même hôte, ou via un en-tête X-GPUStack-Real-IP forgé, et obtenir un accès administratif complet sans authentification.
Avec cet accès, l'attaquant modifie utilisateurs et modèles, crée des clés API administrateur persistantes, lit les secrets des workers et des fournisseurs cloud, puis exécute du code sur les hôtes workers via POST /v2/inference-backends/from-yaml. L'exploitation a été observée en conditions réelles contre un déploiement GPUStack 2.1.1. Le correctif est intégré dans la version 2.2.0. La CVE a été ajoutée au catalogue CISA KEV le 9 novembre 2026, avec une échéance de remédiation fixée au 12 novembre 2026.
Chronologie
| Date | Événement |
|---|---|
| 19 mai 2026 | Ouverture de la pull request #5346 supprimant le contournement d'authentification loopback |
| 18 juin 2026 | Publication de GPUStack 2.2.0 avec le correctif |
| 31 juillet 2026 | Publication de l'avis de sécurité GHSA-gj9m-f8ph-pmhr |
| Non précisée dans les sources | Exploitation observée en conditions réelles contre un déploiement 2.1.1 ; backends personnalisés exécutant des reverse shells |
| 9 novembre 2026 | Ajout au catalogue CISA KEV |
| 12 novembre 2026 | Échéance de remédiation CISA (BOD 26-04) |
Fiche vulnérabilité
CVE-2026-102895 | CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) | GPUStack < 2.2.0
Le contournement repose sur get_current_user dans gpustack/api/auth.py. Avant 2.2.0, lorsque le jeton d'API était absent, la fonction testait si client_ip_getter renvoyait 127.0.0.1. Si c'était le cas et que force_auth_localhost était false (valeur par défaut), elle affectait à user le premier compte is_admin=True. La source réseau d'une requête servait donc de signal d'authentification. Deux chemins permettent de la falsifier. Un reverse proxy sur le même hôte qui relaie via proxy_pass http://127.0.0.1: fait arriver chaque requête distante avec un peer TCP 127.0.0.1. Un en-tête client X-GPUStack-Real-IP: 127.0.0.1 forgé est aussi accepté par client_ip_getter. Le correctif supprime la branche auto-admin loopback et durcit la gestion de l'en-tête de transfert d'IP réelle.
Versions concernées.
| Version | Statut |
|---|---|
| Toutes versions antérieures à 2.2.0 (paquet pip gpustack) | Affectée |
| 2.2.0 et versions ultérieures | Corrigée |
Conditions d'exploitation. Le vecteur est réseau, la complexité d'attaque faible, et aucun privilège ni interaction utilisateur n'est requis. L'attaquant doit atteindre l'API HTTP/HTTPS de GPUStack, directement ou via un reverse proxy qui ne neutralise pas l'en-tête X-GPUStack-Real-IP. L'avis GHSA-gj9m-f8ph-pmhr confirme le contournement de bout en bout contre le commit 6bee5883.
PoC public. Aucun code d'exploitation public autonome n'est référencé dans les sources. L'avis éditeur documente les deux vecteurs de contournement avec une vérification de bout en bout. Cette documentation constitue une description technique reproductible.
Exploitation active. L'avis GHSA confirme une exploitation en conditions réelles. Il mentionne une observation contre un déploiement 2.1.1, où des backends personnalisés créés par l'attaquant exécutaient des reverse shells, signalée par Javier Sixto (ulex.fr). La CVE figure au catalogue CISA KEV depuis le 9 novembre 2026. CISA indique Unknown pour l'usage par rançongiciel. La vulnérabilité a été signalée indépendamment par Nikko Enggaliano, Wei Yunzhou et Rui Yang & Haoyu Wang (Johns Hopkins University).
Diagramme de la chaîne d'attaque

Analyse technique
Étape 1 : accès réseau à l'API GPUStack
L'attaquant cible l'interface d'administration HTTP/HTTPS de GPUStack. Le déploiement peut être atteint directement ou, dans la forme canonique auto-hébergée, derrière un reverse proxy sur le même hôte. Aucun jeton n'est présenté dans la requête.
Étape 2 : falsification de la source loopback
Deux vecteurs aboutissent au même résultat. Un reverse proxy même hôte avec proxy_pass http://127.0.0.1: fait arriver chaque requête distante avec un peer TCP 127.0.0.1. Alternativement, un en-tête X-GPUStack-Real-IP: 127.0.0.1 forgé par le client est accepté par client_ip_getter. Dans les deux cas, la source est considérée comme locale.
Étape 3 : élévation implicite en administrateur
Dans get_current_user, l'absence de jeton combinée à une source 127.0.0.1 et à force_auth_localhost false déclenche l'affectation du premier compte is_admin=True. L'attaquant obtient le contexte administrateur intégré sans identification préalable.
Étape 4 : actions administratives et persistance
Le contexte admin permet d'énumérer et de modifier utilisateurs, modèles, workers et configuration. Il autorise aussi la création de clés API administrateur persistantes avec scope ["*"], valides depuis toute IP, et la lecture des secrets worker et cloud-provider.
Étape 5 : exécution de code sur les workers
L'endpoint administrateur POST /v2/inference-backends/from-yaml permet de déclarer des backends d'inférence personnalisés. Combiné au contexte admin, il aboutit à l'exécution de code sur les hôtes workers. L'observation en conditions réelles mentionne des backends personnalisés exécutant des reverse shells.
Exposition
GPUStack est un composant auto-hébergé. La forme canonique concernée est un déploiement derrière un reverse proxy sur le même hôte, configuration qui fait systématiquement apparaître le trafic distant comme loopback. Les instances dont l'API est joignable depuis des réseaux non fiables ou depuis Internet sont directement exposées. Tout déploiement exécutant une version antérieure à 2.2.0 est concerné, quelle que soit la méthode d'installation. L'impact s'étend aux hôtes workers et aux secrets de fournisseurs cloud lus via l'API.
Indicateurs de compromission
Aucun IOC public documenté à ce jour.
Pistes de détection.
- Journaux d'accès de l'API GPUStack montrant des requêtes réussies vers des endpoints administratifs sans en-tête Authorization valide.
- Présence d'en-têtes X-GPUStack-Real-IP égaux à 127.0.0.1 sur des requêtes externes au reverse proxy.
- Création inattendue de clés API administrateur avec scope ["*"].
- Appels POST /v2/inference-backends/from-yaml non planifiés ou hors fenêtres de changement.
- Apparition de backends d'inférence personnalisés non autorisés.
- Processus de type reverse shell ou connexions sortantes inhabituelles sur les hôtes workers.
MITRE ATT&CK
La cartographie suivante est analytique, aucune cartographie officielle n'étant publiée pour cette CVE.
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Initial Access | Exploit Public-Facing Application | T1190 | L'API HTTP/HTTPS exposée accepte des requêtes non authentifiées élevées en administrateur |
| Defense Evasion | Abuse Elevation Control Mechanism | T1548 | La branche auto-admin de get_current_user promeut tout appelant perçu comme loopback |
| Credential Access | Unsecured Credentials | T1552 | Lecture des secrets worker et cloud-provider après élévation |
| Persistence | Account Manipulation | T1098 | Création de clés API administrateur persistantes |
| Execution | Command and Scripting Interpreter | T1059 | POST /v2/inference-backends/from-yaml aboutit à l'exécution de code sur les workers |
Remédiation : checklist opérationnelle
- Mettre à jour GPUStack vers la version 2.2.0 ou une version ultérieure. Le correctif officiel supprime la branche auto-admin loopback et durcit la gestion de l'IP réelle.
- Si la mise à jour est impossible à court terme, sur une version antérieure à 2.2.0, fixer force_auth_localhost à true pour exiger l'authentification des requêtes loopback.
- Stripper l'en-tête X-GPUStack-Real-IP fourni par le client au niveau de la périphérie ou du reverse proxy. Ne l'accepter que d'une passerelle de confiance.
- Vérifier la configuration du reverse proxy afin qu'il ne présente pas le trafic externe comme 127.0.0.1 auprès de GPUStack.
- Retirer l'API GPUStack des réseaux non fiables, ou la placer derrière un VPN et une authentification en périphérie.
- Révoquer les clés API administrateur créées de façon non autorisée et auditer les comptes administrateurs.
- Rechercher les backends d'inférence personnalisés ajoutés via from-yaml et inspecter les hôtes workers pour des reverse shells.
- Renouveler les secrets worker et cloud-provider susceptibles d'avoir été lus.
- Pour les entités concernées par la BOD 26-04, appliquer les atténuations avant le 12 novembre 2026 et suivre les exigences de tri forensique de la CISA.