GPUStack CVE-2026-102895 : un en-tête qui donne l'accès admin

En bref. GPUStack, logiciel open source qui gère des grappes de GPU pour faire tourner des modèles d'IA, accordait avant sa version 2.2.0 les droits d'administrateur à toute requête qu'il croyait venir de la machine elle-même. Derrière un reverse proxy installé sur le même serveur, ou avec un simple en-tête HTTP falsifié, n'importe qui sur le réseau obtenait ces droits. La faille, CVE-2026-102895, est notée 9.8 sur 10, a été exploitée et fait l'objet de tentatives observées par le SANS Internet Storm Center le 12 novembre 2026. Il faut passer en 2.2.0 ou plus, et vérifier ce qui a pu être créé pendant l'exposition.

Ce qui s'est passé

Le 12 novembre 2026, Johannes Ullrich, du SANS Internet Storm Center (ISC), a publié un journal intitulé Exploit Attempts for GPUStack Authentication Bypass (CVE-2026-102895). Les capteurs de l'ISC voient des requêtes qui tentent ce contournement, toutes venues d'une même adresse IP (144.91.73.103). Les jours précédents, cette adresse cherchait aussi d'autres ressources liées à l'IA, sur des chemins comme /v1/models ou /v1/messages, caractéristiques des API de modèles.

La chronologie, selon l'ISC et l'avis de sécurité du projet :

• toutes les versions antérieures à GPUStack 2.2.0 sont touchées ; la 2.2.0 est sortie fin juin 2026 selon l'ISC ;
• l'avis GitHub GHSA-gj9m-f8ph-pmhr a été publié le 31 juillet 2026 ;
• l'identifiant CVE a été attribué le 4 novembre 2026.

L'avis précise que la faille a été observée exploitée contre une installation en version 2.1.1 : l'attaquant y a créé des backends personnalisés qui ouvraient un accès à distance sur la machine. L'exploitation active a été signalée par Javier Sixto (ulex.fr). La faille a été rapportée de façon indépendante par plusieurs chercheurs, dont une équipe de l'université Johns Hopkins.

Comment fonctionne la faille

Le problème est un schéma d'erreur ancien : prendre la provenance réseau d'une requête pour une preuve d'identité.

Dans GPUStack avant 2.2.0, la fonction qui identifie l'utilisateur promeut au rang d'administrateur intégré toute requête dont la source est considérée comme « loopback », c'est-à-dire la machine locale (127.0.0.1). Ce comportement s'applique quand le réglage force_auth_localhost vaut False, ce qui est la valeur par défaut.

L'avis décrit deux façons d'obtenir cette source « locale » sans aucun identifiant :

1. Le reverse proxy sur la même machine. C'est l'installation classique : un serveur web placé devant GPUStack, sur le même hôte, qui lui transmet les requêtes en local. Toutes les requêtes venues d'Internet arrivent alors chez GPUStack avec une adresse source 127.0.0.1. Aucun en-tête n'est nécessaire : la promotion en administrateur se déclenche pour tout le monde.
2. L'en-tête X-GPUStack-Real-IP. Comme X-Forwarded-For ou X-Real-IP, cet en-tête sert à transmettre l'adresse réelle d'un client derrière un proxy. Il est utile tant qu'il ne sert à aucune décision de sécurité. Ici, un client qui l'envoie lui-même avec une valeur locale peut se faire passer pour la machine.

L'ISC résume la cause : les proxies ajoutent des en-têtes personnalisés, le destinataire leur fait confiance, et un attaquant peut les forger.

Ce que l'attaquant obtient

Selon l'avis, l'accès obtenu est un accès administrateur complet, sans authentification, à travers le réseau :

• lister et modifier les utilisateurs, les modèles, les workers (les machines GPU qui exécutent les modèles) et la configuration ;
• créer des clés d'API administrateur persistantes, valables ensuite depuis n'importe quelle adresse ;
• lire les identifiants des workers et les secrets des fournisseurs cloud ou de modèles enregistrés ;
• combiné à des fonctions réservées à l'administrateur, exécuter du code sur les machines workers.

La notation CVSS (Common Vulnerability Scoring System, l'échelle de gravité standard) est de 9.8 : attaque à distance, faible complexité, sans privilège ni interaction de l'utilisateur. Les faiblesses référencées sont CWE-287 (authentification incorrecte) et CWE-290 (contournement d'authentification par usurpation).

Le point qui rend la remédiation plus longue qu'une mise à jour : les clés d'API créées par un attaquant survivent au correctif. Mettre à jour ferme la porte d'entrée, pas les accès déjà ouverts.

Qui est concerné

• Toute organisation qui fait tourner GPUStack dans une version antérieure à 2.2.0, en particulier derrière un reverse proxy sur le même hôte, ou avec l'API joignable depuis un réseau non maîtrisé.
• Les équipes data ou ML qui ont monté une grappe GPU en dehors du circuit habituel de l'équipe infrastructure. Ce type d'outil est souvent installé vite, pour un projet, puis oublié.
• Les organisations qui ont enregistré dans GPUStack des secrets de fournisseurs cloud ou de modèles : ces secrets sont à considérer comme exposés si l'instance était vulnérable et joignable.

Corriger

L'avis du projet donne une seule correction : passer en GPUStack 2.2.0 ou plus. Dans cette version, le chemin « administrateur automatique en local » a été supprimé et la gestion de l'adresse client et des en-têtes de transfert a été durcie.

En attendant la mise à jour, l'avis liste trois contournements :

• activer force_auth_localhost=true pour exiger une authentification même pour les requêtes locales ;
• s'assurer que le reverse proxy ou la passerelle ne fait pas passer le trafic externe pour du trafic local, et supprimer en bordure tout en-tête X-GPUStack-Real-IP envoyé par un client ;
• garder l'API hors des réseaux non fiables (VPN ou authentification en bordure).

Vérifier si vous avez été touché

Les points suivants sont des bonnes pratiques de réponse à incident, déduites de l'impact décrit dans l'avis. Ils ne figurent pas tels quels dans les sources.

1. Inventaire. Recherchez toutes les instances GPUStack, y compris sur les machines de projet ou de laboratoire, et relevez leur version et leur exposition réseau.
2. Clés d'API. Listez les clés administrateur existantes et révoquez toute clé que personne ne sait expliquer. L'avis indique que les clés créées par ce biais ont une portée totale et restent valides depuis n'importe quelle adresse.
3. Comptes et configuration. Comparez la liste des utilisateurs, des modèles, des workers et des backends d'inférence avec ce que l'équipe a réellement créé. L'exploitation observée passait par des backends personnalisés.
4. Secrets. Faites tourner les secrets de fournisseurs cloud ou de modèles et les identifiants des workers qui étaient enregistrés dans une instance vulnérable et exposée. Surveillez ensuite la consommation des comptes de modèles : un secret de fournisseur volé sert souvent à consommer des API aux frais de la victime.
5. Journaux. Cherchez dans les journaux du reverse proxy les requêtes portant l'en-tête X-GPUStack-Real-IP venant de l'extérieur, ainsi que les requêtes depuis l'adresse signalée par l'ISC.
6. **Machines workers.** Si un backend inconnu a tourné, traitez la machine comme compromise : connexions sortantes, processus et tâches planifiées.

La leçon pour vos autres services

Cette faille n'est pas propre à l'IA. Le schéma « localhost est de confiance » casse dès qu'un reverse proxy est installé sur la même machine, puisque toutes les requêtes semblent alors locales. Et tout en-tête qui transporte une adresse client peut être forgé s'il n'est pas réécrit par une passerelle de confiance.

La correction retenue par le projet résume la règle : ne jamais dériver l'authentification de la source réseau d'une requête, et n'accepter un en-tête d'adresse client que s'il vient d'une passerelle authentifiée. Un test simple à intégrer à vos revues d'architecture : pour chaque service interne, que se passe-t-il si une requête externe arrive avec un en-tête d'adresse qui désigne la machine elle-même ?

FAQ

Qu'est-ce que GPUStack ?

Un logiciel open source qui gère des grappes de GPU, utilisées en général pour faire tourner des modèles d'IA. Il expose une API d'administration et des API de modèles.

Quelles versions sont vulnérables à CVE-2026-102895 ?

Toutes les versions antérieures à 2.2.0. La correction est disponible dans la 2.2.0, sortie fin juin 2026 selon le SANS ISC.

Mon instance n'est pas derrière un proxy, suis-je protégé ?

Pas forcément. Selon l'avis du projet, un en-tête X-GPUStack-Real-IP forgé peut suffire à faire passer une requête pour locale, même sans proxy. Le proxy sur la même machine ouvre simplement une seconde voie, sans aucun en-tête.

La mise à jour suffit-elle ?

Elle ferme la faille. Elle ne supprime pas les clés d'API, comptes ou backends qu'un attaquant aurait créés avant. Une revue de ces éléments et une rotation des secrets enregistrés restent nécessaires si l'instance était exposée.

Sources

• SANS Internet Storm Center, Johannes Ullrich, Exploit Attempts for GPUStack Authentication Bypass (CVE-2026-102895), 12 novembre 2026 : https://isc.sans.edu/diary/33514
• GPUStack, avis de sécurité GHSA-gj9m-f8ph-pmhr, 31 juillet 2026 : https://github.com/gpustack/gpustack/security/advisories/GHSA-gj9m-f8ph-pmhr

---

Pour cartographier et durcir l'infrastructure IA auto-hébergée de vos équipes, WeeSec propose un audit de sécurité IA.