Le 12 octobre 2026, Docker a publié l'avis de sécurité de CVE-2026-105445, surnommée GhostPat. Pendant un peu plus de deux ans, la conversion d'un compte personnel Docker Hub en organisation réaffectait les jetons d'accès personnels (personal access tokens, PAT) du compte converti au propriétaire désigné, sans faire tourner le secret sous-jacent et sans demander confirmation à ce propriétaire. Le secret restant inchangé, celui qui le détenait s'authentifiait désormais comme la cible. Le chemin d'attaque tient en trois gestes : créer un compte, y créer un jeton, convertir le compte en organisation en désignant la cible comme propriétaire. La fenêtre d'exposition court du 26 août 2024 à 20 h 33 UTC au déploiement du correctif, le 30 septembre 2026 aux alentours de 19 h 10 UTC, horaire que l'avis marque comme approximatif. Docker indique n'avoir trouvé aucune preuve d'exploitation après avoir examiné environ 304 000 publications d'images réalisées avec des jetons transférés. La faille a été signalée par Peter Molnar et Krisztian Hozak, de mptrdev.com, et corrigée par Docker en moins de quatre heures.
La mécanique, en une phrase
Docker Hub a changé le propriétaire enregistré d'un jeton sans changer le jeton.
C'est tout le défaut, et il mérite d'être formulé ainsi parce que la formulation contient la leçon. Un jeton d'accès est une paire : un secret, et une identité à laquelle ce secret donne accès. Modifier l'identité sans modifier le secret revient à changer la serrure d'une porte en laissant la clé dans la nature. Le nouveau propriétaire ignore qu'une clé existe ; l'ancien l'a toujours.
| Étape | Effet attendu | Effet réel avant correctif |
|---|---|---|
| Création d'un compte et d'un jeton | Le créateur détient le secret | Idem |
| Conversion du compte en organisation | Les jetons du compte devraient être révoqués | Les jetons sont réaffectés au propriétaire désigné |
| Désignation d'un tiers comme propriétaire | Le tiers reçoit l'organisation | Le tiers reçoit aussi les jetons, sans confirmation ni rotation |
| Usage du jeton par son créateur | Devrait échouer | S'authentifie comme le tiers |
Ce qui a comporté une erreur de conception, ici, n'est pas le transfert de propriété en soi : c'est l'absence de rotation du secret lors d'un changement de titulaire, et l'absence de consentement explicite du nouveau titulaire.
La portée réelle, ni plus ni moins
Les reprises de presse ont parfois présenté l'affaire comme une usurpation de compte. L'avis de Docker est plus précis, et la précision compte pour l'évaluation du risque.
Ce que le jeton permettait, dans la limite de sa portée : récupérer, publier et supprimer des images dans les dépôts de la cible et dans les organisations auxquelles la cible avait accès.
Ce qu'il ne permettait pas : utiliser l'interface web de Docker Hub, changer le mot de passe, l'adresse de courriel ou les paramètres de double authentification de la cible, prendre le contrôle du compte. Le défaut touchait le service hébergé Docker Hub, et non Docker Engine, Docker Desktop ou un paquet installé localement.
L'accès était donc limité au registre. C'est une restriction réelle, et c'est pourtant sur cette base que Docker a classé la vulnérabilité comme critique : publier une image sous un nom légitime est un risque de chaîne d'approvisionnement logicielle. L'avis de Docker ne publie pas de score CVSS ; les analyses externes avancent un 9.4 en CVSS 4.0, chiffre que l'éditeur n'a pas repris.
Le raisonnement de criticité se tient sans le score. Une image poussée sous le nom d'un éditeur de confiance hérite de la confiance de ce nom. Un docker pull qui réussit, sur une étiquette attendue, dans un dépôt attendu, ne produit aucun signal. La confiance dans un registre public n'est pas une confiance dans un contenu vérifié : c'est une confiance dans un contrôle d'accès à la publication. GhostPat attaquait exactement ce contrôle.
L'enquête, et ce qu'elle peut démontrer
Docker rapporte une investigation détaillée, et son honnêteté sur ses propres limites est la partie la plus instructive.
La méthode. Énumération de toutes les conversions de compte depuis le 26 août 2024, corrélation avec les journaux d'authentification du registre, les données d'usage et les enregistrements de jetons du système de gestion des identités, puis examen d'environ 304 000 publications réalisées avec des jetons transférés.
Le résultat. Aucune preuve d'exploitation. Chaque publication examinée a atterri dans les dépôts de l'organisation convertie ou dans les dépôts propres du nouveau propriétaire, aucune dans un compte sans rapport. Une analyse statique, sans exécution, des images publiques les plus à risque n'a révélé ni code malveillant, ni mineur de cryptomonnaie, ni activité de commande et contrôle, ni collecte d'identifiants, ni mécanisme de persistance, ni altération. Aucune preuve non plus que l'infrastructure de Docker ait été affectée.
La limite, énoncée par Docker. Les journaux montrent l'usage d'un jeton, pas son existence. Un jeton transféré mais jamais utilisé ne laisse aucune trace. Docker a donc traité tout jeton transféré pendant la fenêtre comme potentiellement affecté, et c'est la seule conclusion défendable.
Cette distinction entre usage et existence est un principe de journalisation transposable. Un journal d'usage répond à « qui a agi », jamais à « qui pouvait agir ». Pour répondre à la seconde question, il faut un inventaire des accès, pas une trace d'activité. La plupart des organisations n'ont que la trace.
Ce que Docker a fait, et ce que l'utilisateur doit faire
| Date | Action |
|---|---|
| 30 septembre 2026, ~19 h 10 UTC | Déploiement du correctif |
| 2 octobre 2026 | Courriel « Docker Hub Vulnerability Identified & Resolved » aux comptes ayant reçu un jeton transféré |
| 8 octobre 2026, 15 h 45 heure de l'Est | Désactivation des jetons transférés, sauf maintien demandé avant l'échéance |
| 12 octobre 2026 | Publication de l'avis de sécurité |
Pour un utilisateur, la conduite se déduit du courriel du 2 octobre : l'avoir reçu signifie qu'un jeton a été transféré sur le compte, ne pas l'avoir reçu signifie qu'aucun ne l'a été. Dans les deux cas, la revue des jetons sous « Account settings, Personal access tokens » et la révocation de ceux qu'on ne reconnaît pas ou qu'on n'utilise plus est de l'hygiène de base, pas une réaction à l'incident.
La riposte structurelle : trois mesures qui survivent à l'incident
Un correctif côté service ferme ce défaut. Il ne change rien à la classe de risque, qui est la confiance accordée à un registre public. Trois mesures, par ordre croissant de coût et d'efficacité.
1. Épingler par empreinte, pas par étiquette. Une étiquette (:1.4, :latest) est un pointeur mutable : la même étiquette peut désigner un contenu différent demain. Une empreinte (@sha256:...) désigne un contenu et un seul. Référencer les images de base par empreinte dans les fichiers Dockerfile et les manifestes de déploiement rend inopérante toute republication sous un nom légitime : le contenu ne correspond plus, le déploiement échoue. C'est la mesure la moins coûteuse et la plus directement efficace contre le scénario GhostPat.
2. Vérifier les signatures à l'admission. La signature d'images avec Cosign, et la vérification de cette signature dans le contrôleur d'admission du cluster, déplacent la confiance du nom du dépôt vers une clé. Un attaquant qui publie sous un nom légitime sans détenir la clé produit une image que le cluster refuse. C'est la mesure structurante, et celle qui demande le plus de travail de mise en place, parce qu'elle impose de gouverner des clés.
3. Utiliser des identités d'automatisation, pas des identités personnelles. Docker recommande explicitement les jetons d'accès d'organisation pour les automatisations. La raison dépasse largement cette vulnérabilité : un jeton personnel suit son porteur, pas la fonction. Il survit à un départ, à un changement d'équipe, à une conversion de compte, et son cycle de vie échappe à l'organisation qui en dépend. Les chaînes d'intégration continue adossées au jeton personnel d'un développeur sont une dette d'identité, indépendamment de tout défaut du fournisseur.
La leçon de conception : la rotation est un invariant du transfert
GhostPat n'est pas une faille d'authentification, ni une faille d'autorisation au sens classique. C'est un défaut du cycle de vie d'un secret.
Le modèle mental à retenir se formule en une règle : tout changement de titulaire d'un secret impose la rotation de ce secret. Sans exception, et quelle que soit la raison du changement : conversion de compte, transfert de dépôt, fusion d'organisations, changement de propriétaire d'un projet, reprise d'un service par une autre équipe.
Le corollaire est symétrique et aussi important : recevoir un accès se consent. Un propriétaire qui hérite silencieusement d'un jeton ne peut pas le gouverner, puisqu'il ignore son existence. La notification n'est pas une politesse, c'est la condition pour que la responsabilité soit exerçable.
Ces deux règles valent pour toute plateforme qui permet le transfert de propriété, et la liste est longue : forges logicielles, registres de paquets, fournisseurs d'infrastructure, plateformes d'intégration continue. L'affaire Docker Hub est un cas d'école, pas une singularité.
Pour aller plus loin
Les contre-mesures citées sont détaillées dans la sécurité des images de conteneurs, qui couvre l'épinglage par empreinte et la signature. Les bases du modèle de confiance Docker sont dans sécurité Docker, les bases. Pour la gestion des secrets dans les chaînes d'intégration, voir scan des secrets dans les pipelines.
Sources
- Docker, « Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions », 12 octobre 2026.
- BleepingComputer, « Docker Hub flaw let attackers impersonate users, tamper with images », octobre 2026.
- The Hacker News, « Docker fixes critical two-year-old Hub flaw », octobre 2026.
- Signalement par Peter Molnar et Krisztian Hozak, mptrdev.com.
