GPUStack CVE-2026-102895 : accès admin sans mot de passe derrière un reverse proxy, exploitée en conditions réelles, passez en 2.2.2 ou 2.3.0

Le 9 novembre 2026, la CISA a ajouté CVE-2026-102895 à son catalogue des vulnérabilités exploitées (KEV), sous le nom « GPUStack Improper Authentication Vulnerability ». La faille, notée CVSS 9.8, touche toutes les versions de GPUStack antérieures à la 2.2.0 : le gestionnaire de clusters GPU open source considère comme l'administrateur intégré toute requête dont l'adresse source paraît être 127.0.0.1, dès lors que le paramètre force_auth_localhost garde sa valeur par défaut, false. Un Nginx ou un Caddy installé sur le même serveur, qui relaie vers 127.0.0.1 comme le font tous les tutoriels de reverse proxy, transforme donc chaque visiteur anonyme en administrateur sans identifiant ni mot de passe. Un en-tête X-GPUStack-Real-IP: 127.0.0.1 ajouté à la main produit le même effet. L'éditeur confirme une exploitation en conditions réelles contre une instance 2.1.1, où les attaquants ont créé des backends d'inférence personnalisés qui lançaient des reverse shells sur les workers GPU. Une seconde faille critique, CVE-2026-102894 (CVSS 9.1), permet d'obtenir la session de n'importe quel administrateur via le callback SAML, même sur une instance qui n'utilise pas le SSO. Si vous faites tourner GPUStack sur un serveur dédié ou une machine en housing GPU, la mise à jour vers la 2.2.2 au minimum, ou directement vers la 2.3.0, ne se discute pas, et elle ne suffit pas : il faut aussi faire le ménage dans les clés API, les comptes et les backends.

Sources : avis GHSA-gj9m-f8ph-pmhr publié par GPUStack, 31 juillet 2026 ; avis GHSA-62m9-f875-rqw6, 30 septembre 2026 ; fiches CVE-2026-102895 et CVE-2026-102894 publiées par GitHub en tant que CNA le 4 novembre 2026 ; catalogue KEV de la CISA, entrée du 9 novembre 2026 ; notes de version GPUStack v2.2.0, v2.2.2 et v2.3.0 ; documentation GPUStack (installation Docker, mise à niveau, référence CLI) ; documentation nginx et Caddy, consultées le 9 novembre 2026.

GPUStack : le gestionnaire de cluster GPU qui orchestre vLLM et SGLang

GPUStack se présente comme un gestionnaire de clusters GPU open source pour le service de modèles d'IA et le provisionnement d'instances GPU. Concrètement, un serveur GPUStack pilote un ou plusieurs workers, chacun installé sur une machine équipée de cartes NVIDIA, AMD, Ascend ou d'autres accélérateurs, et déploie dessus des moteurs d'inférence : vLLM, SGLang et TensorRT-LLM sont configurés automatiquement, et l'administrateur peut ajouter des backends d'inférence personnalisés sous forme de définition YAML qui décrit une image de conteneur, une commande et des arguments à exécuter sur les workers. Le tout s'expose via des API d'inférence standard, une interface web, des clés API à permissions (gestion de la plateforme, accès aux modèles) et un SSO optionnel (OIDC, SAML, CAS). La version 2, sortie le 23 novembre 2025, a abandonné SQLite pour un PostgreSQL embarqué et ne documente plus que l'installation par Docker, Helm ou en mode déconnecté, même si le paquet gpustack reste publié sur PyPI.

Pour un hébergeur ou un administrateur, c'est la couche qui transforme un serveur dédié à GPU ou un parc de machines en housing en service d'inférence partagé entre plusieurs équipes. C'est aussi, de fait, un composant qui détient des secrets : identifiants des workers, jetons d'enregistrement, clés de fournisseurs cloud, et la capacité de lancer n'importe quel conteneur sur n'importe quel worker. En octobre 2026, une campagne de cryptominage sur Hugging Face visait déjà le répertoire /var/lib/gpustack dans son script d'évasion de conteneur, comme nous le rapportions dans notre article sur le cryptomineur load-mine. Les attaquants savent ce que vaut un serveur GPU.

CVE-2026-102895 : quand 127.0.0.1 vaut un mot de passe administrateur

Le défaut se situe dans la fonction get_current_user du fichier gpustack/api/auth.py. Dans les versions antérieures à la 2.2.0, cette fonction promeut au rang d'administrateur intégré toute requête dont la source est considérée comme locale (loopback), tant que force_auth_localhost vaut false, sa valeur par défaut. L'intention était de laisser l'administrateur travailler depuis la machine elle-même sans s'authentifier. Le problème est la manière dont la source est déterminée : une fonction nommée client_ip_getter dérive l'adresse du client soit du pair TCP, soit d'un en-tête HTTP, X-GPUStack-Real-IP, que n'importe quel client peut écrire. L'avis de sécurité classe le défaut sous trois faiblesses : authentification incorrecte (CWE-287), contournement par usurpation (CWE-290) et erreur de validation d'origine (CWE-346). Il y a donc deux façons d'être pris pour 127.0.0.1 :

Une fois administrateur, l'attaquant dispose, d'après l'avis, de tout ce que l'interface permet : lister et modifier les utilisateurs, les modèles, les workers et la configuration ; créer des clés API administrateur persistantes à portée totale (["*"]) qui survivent à la fermeture de la session ; lire les identifiants des workers et les secrets des fournisseurs cloud ; et surtout appeler POST /v2/inference-backends/from-yaml, la route qui enregistre un backend d'inférence personnalisé à partir d'un YAML. Comme un backend décrit une image et une commande que les workers exécutent, cette route donne l'exécution de code sur les hôtes GPU. C'est exactement la chaîne observée en conditions réelles : l'éditeur rapporte une exploitation contre un déploiement en version 2.1.1, avec des backends personnalisés créés par l'attaquant qui faisaient tourner des reverse shells. Le signalement de cette exploitation est crédité à Javier Sixto (ulex.fr) ; la faille elle-même a été rapportée indépendamment par Nikko Enggaliano, par Wei Yunzhou et par Rui Yang et Haoyu Wang de l'université Johns Hopkins.

Côté calendrier, la correction est arrivée bien avant la publicité : la 2.2.0 du 18 juin 2026 supprime le chemin « loopback = administrateur » et durcit le traitement de l'adresse client et des en-têtes de relais. L'avis GHSA a été publié le 31 juillet, l'identifiant CVE le 4 novembre par GitHub en tant qu'autorité de numérotation, et l'enrichissement de la CISA a basculé le statut d'exploitation à « active » le 9 novembre, jour de l'ajout au catalogue KEV. Pour les agences fédérales américaines, la date limite de correction fixée par la CISA est le 12 novembre 2026, soit trois jours : c'est rare, et c'est un indicateur de l'urgence perçue. Si votre instance a tourné en version 2.1.x ou antérieure derrière un proxy ces derniers mois, partez du principe qu'elle a pu être visitée.

CVE-2026-102894 : le callback SAML qui croit n'importe quel XML

La seconde faille, publiée le 30 septembre 2026 sous l'avis GHSA-62m9-f875-rqw6, est indépendante de la première mais tout aussi critique : CVSS 9.1, sans authentification, sans interaction. Le gestionnaire de la route /auth/saml/callback décode le XML posté en Base64, en lit le NameID et les attributs, retrouve ou crée l'utilisateur correspondant, puis émet un jeton de session gpustack_session. Ce qu'il ne fait jamais, c'est appeler OneLogin_Saml2_Auth.process_response(), l'étape qui vérifie la signature, l'émetteur, l'audience, la destination et la fenêtre de validité. Autrement dit, le serveur accepte une réponse SAML non signée écrite par l'attaquant. Si le nom d'utilisateur indiqué correspond à un compte existant, par exemple admin, l'attaquant reçoit la session de ce compte ; sinon, un nouvel utilisateur non administrateur est créé. Les identifiants de réponse n'étant pas consommés, une réponse signée capturée peut aussi être rejouée indéfiniment.

Le point qui surprend le plus : la route est active sur toutes les instances, même celles qui n'ont jamais configuré de fournisseur SAML. L'avis est explicite, chaque déploiement est concerné, pas seulement ceux qui utilisent le SSO. Les versions touchées vont de la 0.7.1 à la 2.2.1, et la correction est dans la 2.2.2 du 24 juillet 2026 : le callback passe désormais par la validation complète, et les routes SAML et OIDC ne sont montées que lorsque le fournisseur correspondant est configuré comme fournisseur actif. Aucun paramètre ne permet de contourner le problème sans mettre à jour ; la seule mesure temporaire est de bloquer l'accès réseau à /auth/saml/callback au niveau du reverse proxy ou du pare-feu. L'avis signale aussi une limite connue des versions corrigées : le rejeu reste possible pendant la durée de validité d'une assertion, d'où l'intérêt de durées courtes côté fournisseur d'identité et de HTTPS sur tout le trafic SSO. La faille a été rapportée par Austin Chu, Sohee Kim et Corban Villa (projet de recherche en sécurité de l'université de Californie à Berkeley), et plus tôt par un chercheur anonyme ; aucune exploitation en conditions réelles n'est signalée pour celle-ci. Si vous centralisez vos identités avec un fournisseur SSO auto-hébergé comme dans notre guide Keycloak avec Docker sur un VPS Linux, retenez la leçon générale : un service qui expose un callback SAML ou OIDC doit vérifier la signature avant toute autre chose.

Vérifier la version installée et l'exposition de votre instance

Première chose à savoir : quelle version tourne. Le binaire gpustack dispose d'une sous-commande version. Avec l'installation Docker documentée par l'éditeur, le conteneur s'appelle gpustack :

# Installation Docker (serveur et workers)
docker exec gpustack gpustack version
docker inspect --format '{{.Config.Image}}' gpustack

# Installation pip (anciennes installations ou environnement virtuel)
pip show gpustack
gpustack version

Comparez le numéro obtenu au tableau suivant, construit à partir des notes de version et des avis de sécurité publiés par GPUStack.

Deuxième vérification : l'exposition. Regardez comment votre proxy parle à GPUStack. Si la configuration contient un relais vers l'adresse de bouclage, chaque visiteur a été administrateur tant que la version était inférieure à 2.2.0 :

# Nginx
grep -rn 'proxy_pass' /etc/nginx/ | grep -E '127\.0\.0\.1|localhost'

# Caddy
grep -n 'reverse_proxy' /etc/caddy/Caddyfile

# Le conteneur écoute-t-il sur toutes les interfaces ?
docker port gpustack
ss -ltnp | grep -E ':80 |:443 |:30080 |:30079 '

Par défaut, l'image Docker publie le port 80 sur toutes les interfaces (-p 80:80), et la référence CLI documente aussi un port API 30080 et un port proxy 30079. Un GPUStack joignable directement depuis Internet, sans proxy, est vulnérable au second scénario, celui de l'en-tête forgé, et il l'est depuis n'importe où. Notre guide Nginx en reverse proxy sur VPS Linux rappelle le réflexe de base : publier le conteneur sur 127.0.0.1 uniquement, et laisser le proxy porter le TLS. C'est précisément ce réflexe, sain par ailleurs, qui rendait GPUStack ouvert à tous. Troisième vérification, les journaux du proxy : cherchez des appels à la route d'ajout de backend et des POST inattendus sur les routes d'administration.

grep -h 'inference-backends/from-yaml' /var/log/nginx/access.log*
grep -h 'auth/saml/callback' /var/log/nginx/access.log*
# Toutes les écritures sur l'API, par route et par adresse source
grep -hE '"(POST|PUT|DELETE) /v2/' /var/log/nginx/access.log* | awk '{print $1, $6, $7}' | sort | uniq -c | sort -rn | head -30

Les deux premières routes sont celles que citent les avis de sécurité ; la troisième commande liste toutes les écritures sur l'API, à comparer avec ce que votre équipe a réellement fait. Les autres chemins de l'API se lisent dans le Swagger intégré, accessible sur /docs depuis l'URL de votre serveur GPUStack.

Mettre à jour : 2.2.2 au minimum, 2.3.0 de préférence

La 2.2.0 suffit à fermer CVE-2026-102895, mais la 2.2.2 est le vrai plancher puisqu'elle ferme aussi le callback SAML et le proxy Kubernetes. La 2.3.0 ajoute les huit corrections du 26 octobre, dont plusieurs contournements d'autorisation entre clusters et un problème de permissions sur les fichiers contenant la clé de signature des JWT : sur un serveur partagé, c'est elle qu'il faut viser. La procédure documentée par GPUStack pour Docker tient en quelques commandes. Sauvegardez d'abord la base : avec le PostgreSQL embarqué, arrêtez le serveur et copiez le répertoire /var/lib/gpustack/postgresql/data du volume ; avec une base externe, suivez la procédure de votre moteur. Mettez ensuite à jour le serveur en premier, puis les workers, en reprenant exactement les options de votre docker run d'origine (ports, volumes, variables d'environnement) :

# 1. Sauvegarde du PostgreSQL embarqué
docker stop gpustack
docker run --rm -v gpustack-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/gpustack-pg-$(date +%F).tgz -C /data postgresql/data
docker start gpustack

# 2. Nouvelle image, à version explicite plutôt que latest
docker pull gpustack/gpustack:v2.3.0

# 3. Recréer le conteneur avec les mêmes options qu'à l'installation
docker stop gpustack
docker rm gpustack
docker run -d --name gpustack --restart unless-stopped \
  -p 127.0.0.1:8080:80 \
  --volume gpustack-data:/var/lib/gpustack \
  gpustack/gpustack:v2.3.0

# 4. Vérifier
docker exec gpustack gpustack version
docker logs --tail 50 gpustack

Si vous avez déployé avec le fichier Compose du dépôt, la documentation indique de récupérer les tags (git fetch --tags), de passer sur le tag voulu, puis d'enchaîner docker compose -f docker-compose.server.yaml pull et up -d ; notre guide Docker Compose sur VPS Linux couvre ce cycle. Pour une installation par pip, héritée des versions 0.x ou faite dans un environnement virtuel, le paquet 2.3.0 est sur PyPI depuis le 23 octobre :

source /chemin/vers/venv/bin/activate
pip install -U gpustack
pip show gpustack | grep Version
systemctl restart gpustack   # ou le nom de votre unité

Ne vous arrêtez pas au serveur : l'avis sur l'API de gestion des workers corrigé en 2.3.0 précise que les workers, y compris le worker embarqué dans le serveur, doivent eux aussi être mis à jour. Un worker en 2.2.x derrière un serveur 2.3.0 reste une porte entrouverte.

En attendant la mise à jour : quatre mesures, dans cet ordre

Une fenêtre de maintenance peut prendre quelques jours quand des modèles sont en production. Voici ce que recommande l'éditeur pour tenir d'ici là, et ce que chaque mesure couvre réellement.

1. Forcer l'authentification du loopback. C'est la seule mesure qui ferme réellement CVE-2026-102895 sans mise à jour, car elle désactive la promotion automatique. Le paramètre s'appelle force_auth_localhost ; en ligne de commande c'est --force-auth-localhost, et la documentation précise que tout paramètre CLI peut aussi se passer en variable d'environnement préfixée GPUSTACK_ en majuscules. Avec Docker, ajoutez l'option à la fin de la commande de lancement ou la variable d'environnement, puis recréez le conteneur :

docker stop gpustack && docker rm gpustack
docker run -d --name gpustack --restart unless-stopped \
  -p 127.0.0.1:8080:80 \
  -e GPUSTACK_FORCE_AUTH_LOCALHOST=true \
  --volume gpustack-data:/var/lib/gpustack \
  gpustack/gpustack:v2.1.1

À noter : dans la référence CLI de la 2.3.0, cette option est marquée « obsolète, sans effet », avec la mention que les appels locaux sont désormais toujours authentifiés. Elle n'a de sens que sur les versions vulnérables.

2. Supprimer l'en-tête X-GPUStack-Real-IP au niveau du proxy. Cette mesure ferme le scénario de l'en-tête forgé, mais pas celui du proxy local : si Nginx relaie vers 127.0.0.1, le pair TCP reste local quoi que fassent les en-têtes. Elle complète donc la mesure 1, elle ne la remplace pas. Dans Nginx, un en-tête défini à une chaîne vide n'est pas transmis au serveur amont ; dans Caddy, le préfixe - de header_up supprime un en-tête entrant. Profitez-en pour bloquer le callback SAML (mesure 3) au même endroit :

# Nginx : /etc/nginx/sites-available/gpustack.conf
location = /auth/saml/callback {
    return 403;
}

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-GPUStack-Real-IP "";
}

# Caddy : Caddyfile
gpustack.exemple.fr {
    respond /auth/saml/callback 403
    reverse_proxy 127.0.0.1:8080 {
        header_up -X-GPUStack-Real-IP
    }
}

3. Bloquer /auth/saml/callback. C'est l'unique contournement de CVE-2026-102894, et il vaut même pour les instances qui n'utilisent pas SAML. Au niveau du proxy comme ci-dessus, ou dans le pare-feu si GPUStack est exposé directement, ce qui nous amène à la dernière mesure.

4. Ne pas exposer l'API hors d'un VPN. L'éditeur le dit sans détour : gardez l'API à l'écart des réseaux non fiables, derrière un VPN ou une authentification en bordure. Sur un serveur GPU, cela veut dire publier le conteneur sur 127.0.0.1, ouvrir le pare-feu aux seules adresses de confiance, et accéder à l'interface via Tailscale ou WireGuard plutôt que par un nom de domaine public. Notre guide sur nftables comme pare-feu d'un serveur Linux donne la base ; un exemple minimal avec UFW :

# Autoriser l'interface GPUStack uniquement depuis le réseau VPN
sudo ufw allow from 100.64.0.0/10 to any port 443 proto tcp
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp
sudo ufw status numbered

Rappel utile pour Docker : un port publié avec -p 80:80 contourne les règles UFW, car Docker écrit ses propres règles dans la table NAT. Publier sur 127.0.0.1:8080:80 et passer par le proxy reste la manière fiable de ne rien exposer par accident ; nous rappelons ce piège dans le guide installer Docker sur un VPS.

Après la mise à jour : révoquer, auditer, supprimer

La mise à jour ferme la porte, elle ne fait pas sortir ceux qui sont déjà entrés. L'avis le souligne : les clés API créées par un attaquant sont persistantes, et la mise à jour ne révoque ni les clés, ni les comptes, ni les backends créés pendant la période vulnérable. Si votre instance a tourné en version antérieure à 2.2.0 derrière un proxy local, ou exposée directement, traitez-la comme potentiellement compromise et déroulez les contrôles suivants depuis l'interface d'administration.

Clés API. Dans la section Access Control, page API Keys, passez en revue chaque clé : nom, propriétaire, permissions (Platform Management ou Model Access), date de création. Supprimez toute clé que vous ne reconnaissez pas ; la documentation indique que la suppression est répercutée à la passerelle en quelques secondes. La documentation précise que chaque utilisateur gère ses propres clés : vérifiez donc aussi celles du compte admin lui-même, qui est le compte usurpé par la faille. Par prudence, régénérez ensuite toutes les clés légitimes et mettez à jour les applications qui les utilisent.

Comptes utilisateurs. Listez les utilisateurs et supprimez les comptes inconnus, en particulier ceux qui ont le rôle administrateur ou qui ont été créés sans que personne ne s'en souvienne. Le callback SAML non vérifié pouvait provisionner des comptes non administrateurs : ils sont faciles à repérer si vous n'utilisez pas le SSO. Changez le mot de passe du compte admin.

Backends d'inférence. Dans Model Service, page Inference Backends, chaque backend apparaît sous forme de carte. D'après la documentation, le nom d'un backend personnalisé se termine obligatoirement par -custom, ceux activés depuis la place de marché communautaire portent l'étiquette de source « community », et les backends intégrés ne peuvent pas être supprimés. Ouvrez chaque backend personnalisé et lisez sa définition : image, point d'entrée, commande et arguments. Un backend légitime exécute un moteur d'inférence ; un backend malveillant exécute un shell, un curl | sh, un nc, un bash -i ou un script Python qui ouvre une connexion sortante. Supprimez tout ce que vous n'avez pas créé vous-même, ainsi que les déploiements de modèles qui s'appuyaient dessus.

Workers. Un reverse shell lancé par un backend est un conteneur ou un processus sur l'hôte GPU. Sur chaque worker, cherchez les connexions sortantes établies vers des adresses inconnues et les conteneurs qui ne correspondent à aucun déploiement actuel :

ss -tnp state established | grep -vE ':(443|80|22) '
docker ps --format '{{.ID}}\t{{.Image}}\t{{.Command}}\t{{.Names}}'
ps -eo pid,user,etimes,cmd --sort=-etimes | grep -E 'bash -i|/dev/tcp|nc |ncat|socat|python.* -c' | grep -v grep
crontab -l ; ls -la /etc/cron.d /var/spool/cron/crontabs 2>/dev/null
cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys 2>/dev/null

Si vous trouvez quelque chose, ne nettoyez pas à la main : un hôte sur lequel un attaquant a exécuté du code en tant que worker GPU se réinstalle. Conservez les journaux, retirez le worker du cluster, réinstallez le système, réenregistrez le worker avec un nouveau jeton. Pensez aussi aux secrets lisibles par un administrateur usurpé : identifiants de fournisseurs cloud, jetons d'enregistrement des workers, et, d'après l'avis corrigé en 2.3.0, la clé de signature des JWT qui était lisible par tous les utilisateurs locaux du serveur. Faites-les tous tourner. Pour la suite, une détection d'intrusion comme CrowdSec sur le proxy et une trace d'exécution avec auditd sur les workers vous donneront autre chose que les journaux d'accès pour répondre à la question « que s'est-il passé ».

Checklist pour l'administrateur d'un serveur GPUStack

1. Relevez la version de chaque serveur et de chaque worker (docker exec gpustack gpustack version ou pip show gpustack). Toute version inférieure à 2.2.0 est exposée à CVE-2026-102895, toute version de 0.7.1 à 2.2.1 à CVE-2026-102894.
2. Regardez si votre reverse proxy relaie vers 127.0.0.1 ou si l'API est publiée directement sur Internet : dans les deux cas, considérez que l'instance a pu être administrée par des inconnus.
3. Si vous ne pouvez pas mettre à jour dans l'heure, activez force_auth_localhost=true, supprimez l'en-tête X-GPUStack-Real-IP au niveau du proxy, bloquez /auth/saml/callback et restreignez l'accès au VPN.
4. Sauvegardez le PostgreSQL embarqué, puis passez le serveur puis les workers en 2.3.0 (2.2.2 au strict minimum), avec un tag de version explicite plutôt que latest, et sans toucher aux versions rc.
5. Supprimez les clés API inconnues, régénérez les clés légitimes, supprimez les comptes inconnus, changez le mot de passe admin.
6. Supprimez les backends d'inférence personnalisés que vous n'avez pas créés et les déploiements qui en dépendent ; inspectez les workers (connexions sortantes, conteneurs, cron, clés SSH) et réinstallez tout hôte suspect.
7. Faites tourner les secrets que l'administrateur pouvait lire : identifiants cloud, jetons de workers, clé de signature des JWT.
8. Appliquez les premiers réglages de sécurisation d'un serveur dédié et durcissez SSH sur les workers : un reverse shell cherche toujours à s'installer durablement.

Conclusion

CVE-2026-102895 n'est pas une faille exotique, c'est une décision de conception qui a mal vieilli : faire confiance à l'adresse source d'une requête comme preuve d'identité. Le reverse proxy local, geste d'hygiène que nous recommandons sur chaque VPS Linux et chaque serveur dédié, suffisait à la déclencher, et les attaquants l'ont exploitée pour poser des reverse shells sur des workers GPU avant même que l'identifiant CVE n'existe. La 2.2.0 a corrigé le mécanisme en juin, la 2.2.2 a fermé le callback SAML en juillet, la 2.3.0 a nettoyé huit contournements d'autorisation en octobre, et la CISA a inscrit la faille à son catalogue le 9 novembre avec trois jours de délai. Pour un administrateur, la séquence est claire : vérifier la version, mettre à jour serveur et workers en 2.3.0, puis révoquer les clés, les comptes et les backends que la mise à jour laisse en place. Et, de manière plus générale, ne jamais laisser un service d'inférence répondre à Internet sans une authentification dont vous connaissez le fonctionnement.