Docker Hub réassignait les jetons personnels sans renouveler leur secret pendant vingt-cinq mois
Le 12 octobre 2026, Docker révèle que la conversion d’un compte en organisation réassignait les jetons d’accès personnels à un nouveau propriétaire sans renouveler le secret. Traitez le nom d’espace d’une image comme un signal de confiance faible : passez aux jetons d’organisation et signez vos images.
30 septembre 2026. Deux chercheurs signalent à Docker une faille dans la gestion des identités de Docker Hub. Le correctif est en production moins de quatre heures plus tard. 12 octobre 2026. Docker publie l’avis officiel CVE-2026-105445. Pourquoi c’est important : pendant vingt-cinq mois, la conversion d’un compte personnel en organisation a réassigné des jetons d’accès personnels à un nouveau propriétaire sans renouveler ni révoquer leur secret. Un attaquant qui conservait ce secret pouvait alors pousser ou supprimer des images sous l’identité de sa victime.
Une réassignation d’identité qui laisse le secret intact
Le défaut se niche dans une fonction banale : la conversion d’un compte en organisation. Docker Hub ne permet pas de déplacer un dépôt d’un compte à un autre. Pour transformer alice/app en dépôt détenu par une organisation sans casser les docker pull existants, on convertit le compte et l’on désigne un compte existant comme propriétaire de la nouvelle organisation.
Le problème est apparu le 26 août 2024. À partir de cette date, la conversion réassignait aussi les jetons d’accès personnels (PAT) du compte converti vers le nouveau propriétaire — en modifiant simplement l’enregistrement du propriétaire du jeton, sans faire tourner ni révoquer le secret. Le propriétaire désigné n’était ni invité à confirmer, ni notifié. La combinaison des deux lacunes rendait l’exploitation triviale :
- L’attaquant crée un compte et génère un PAT dessus.
- Il convertit ce compte en organisation en désignant sa victime comme propriétaire.
- Le PAT est réassigné à la victime, mais l’attaquant détient toujours le secret.
- Le jeton s’authentifie désormais auprès du registre en tant que la victime.
Un PAT ainsi réassigné agissait comme la victime au niveau du registre, dans la limite des droits du jeton : pousser, tirer et supprimer des images dans les dépôts de la victime et dans les organisations où elle avait accès. Comme cela inclut la publication d’images sous un nom légitime, Docker a traité le problème comme un risque de chaîne d’approvisionnement logicielle et l’a classé critique. La faille, référencée CWE-266, n’autorisait en revanche ni accès à l’interface web, ni modification du mot de passe ou des réglages 2FA, ni prise de contrôle du compte.
Quatre heures pour corriger, vingt-cinq mois pour s’en apercevoir
La chronologie de la réponse est un modèle de divulgation responsable. Le 30 septembre à 11 h 40, les chercheurs Peter Molnar et Krisztian Hozak de mptrdev.com signalent le problème. Docker le reproduit vers 13 h 30, déploie le correctif vers 15 h 10 — la conversion ne transfère plus les PAT — et informe les chercheurs à 16 h 59. Le 2 octobre à 17 h 30, les utilisateurs exposés sont notifiés par courriel. Le 8 octobre, Docker désactive de force tous les PAT transférés par conversion, sauf ceux dont le titulaire a demandé le maintien. Les chercheurs ont publié leur analyse sous le nom GhostPAT.
Le contraste est saisissant, et c’est lui qui donne la leçon. La correction a pris moins de quatre heures. La détection, elle, a pris vingt-cinq mois : la faille est née le 26 août 2024 et n’a été refermée que le 30 septembre 2026. Une vulnérabilité d’identité ne laisse aucune trace visible tant qu’elle n’est pas exploitée — c’est précisément ce qui la rend dangereuse.
Ce que l’enquête a trouvé, et ce qu’elle n’a pas pu trouver
Docker a énuméré chaque conversion effectuée depuis le 26 août 2024 et l’a corrélée aux journaux d’authentification du registre, aux données d’usage et aux enregistrements de jetons. Verdict : aucune preuve d’exploitation. Sur environ 304 000 poussées effectuées avec un jeton transféré, toutes sont arrivées dans les dépôts de l’organisation convertie ou du propriétaire désigné. Dans la majorité des cas, la même personne contrôlait les deux comptes — l’usage légitime de la fonction. L’analyse statique des images publiques à plus haut risque n’a trouvé ni malware, ni cryptominer, ni commande-et-contrôle, ni collecte d’identifiants, ni persistance, ni altération.
Le point important est la limite que Docker reconnaît lui-même. Les journaux du registre indiquent quand un jeton est utilisé, pas qu’il existe. Un PAT transféré qui n’a jamais servi ne laisse aucune trace. L’éditeur n’a donc pas fondé sa décision sur la détection : il a traité chaque jeton passé par une conversion pendant la fenêtre comme potentiellement affecté, qu’il ait ou non observé son usage.
Trois changements qui comptent plus que le correctif
Le correctif immédiat supprime le transfert des PAT lors de la conversion. Mais les trois engagements annoncés sont plus structurants :
- Consentement obligatoire avant de désigner un propriétaire d’organisation, avec notification.
- Historique auditable de chaque changement de propriété d’un jeton, pour répondre par des enregistrements plutôt que par inférence.
- Revue des autres flux qui modifient la propriété d’identifiants, à la recherche du même schéma.
C’est le vrai enseignement de l’épisode. Une faille qui porte sur l’identité d’un jeton — et non sur sa cryptographie — est exactement le genre de défaut que ni les scanners de vulnérabilités ni les audits de code ne détectent. Elle se corrige en quelques heures, mais elle n’apparaît que si quelqu’un pose la bonne question : que se passe-t-il quand ce jeton change de propriétaire ?
La chaîne d’approvisionnement ne s’arrête pas au nom d’espace
Cet épisode s’inscrit dans une série plus large, où la confiance dans un écosystème de paquets s’effondre à cause d’une identité, pas d’un code. Les écosystèmes npm et PyPI ont connu des campagnes équivalentes — ce blog a documenté la campagne MALFEX, qui cachait un chargeur de shellcode dans un module natif npm encore en ligne. Le point commun est toujours le même : l’attaquant ne casse pas la cryptographie, il usurpe la légitimité d’un éditeur.
C’est précisément pour cela que les mécanismes de signature existent. Le projet Sigstore, porté par Cosign, permet de signer une image et de vérifier cette signature avant tout déploiement, indépendamment de ce que prétend le nom d’espace. Un PAT fantôme peut pousser une image sous le nom de sa victime, mais il ne peut pas produire la signature de cette victime. La chaîne de confiance se déplace ainsi du nom vers la clé :
# Épingler une image par digest plutôt que par un tag mutable
docker pull alpine@sha256:9a839e63dad54c3a6d1834e29692c8492d93f90c59c978c1ed79109ea4fb9a54
# Vérifier la signature avant tout déploiement
cosign verify \
--certificate-identity [email protected] \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
myorg/app:latestLa leçon opérationnelle tient en une phrase : le nom d’espace est un signal faible, la signature est le seul signal fort. Un registre qui laisse un jeton changer de propriétaire sans changer de secret rappelle à quel point le premier est fragile.
Verdict
Si vous publiez des images sur un registre public, partez du principe que le nom d’espace ne prouve rien : un jeton qui a changé de mains sans changer de secret rend caduque la confiance qu’on accorde au nom d’un éditeur. Concrètement, passez vos automatisations sur des jetons d’organisation plutôt que sur des PAT personnels, révoquez les jetons que vous ne reconnaissez plus, et signez vos images avec Cosign ou une attestation équivalente — c’est la signature, pas le nom, qui est la vraie frontière de confiance. Si vous consommez des images, activez la vérification de signature et épinglez vos dépendances par digest, pas par tag.