veilletech.fr
13 oct. Feed du jour
#01 SÉCURITÉ Faille

Docker Hub : un jeton changeait de propriétaire

Un jeton qui change de main sans qu'on vous le dise reste un jeton valide.

Docker a détaillé le 12 octobre CVE-2026-105445, notée critique : depuis le 26 août 2024, convertir un compte Docker Hub en organisation réattribuait ses jetons d'accès personnels au propriétaire désigné, sans les révoquer ni demander son accord. Le correctif est en production depuis le 30 septembre. Docker ne voit aucune exploitation, mais un jeton jamais utilisé ne laisse pas de trace : les jetons concernés ont été désactivés le 8 octobre.

4 min de lectureintermédiairevidéo 1:16
Partager
Sommaire7 sections
  1. Ce qui se passe
  2. Le mécanisme
  3. Ce que le jeton permettait
  4. Ce que Docker a vérifié
  5. Chronologie (heure de la côte Est)
  6. Comment s'y prendre
  7. À retenir

Ce qui se passe

Docker a publié le 12 octobre l'avis de sécurité de CVE-2026-105445, une faille de la gestion des identités de Docker Hub qu'il note critique. Elle a été signalée le 30 septembre par Peter Molnar et Krisztian Hozak (mptrdev.com), qui détaillent leur découverte sur ghostpat.com, et corrigée en production le jour même, moins de quatre heures après le signalement.

La fenêtre d'exposition court du 26 août 2024, 20 h 33 UTC, jusqu'au 30 septembre 2026, vers 19 h 10 UTC.

Le mécanisme

Docker Hub ne sait pas déplacer un dépôt d'un compte à un autre. Pour que alice/app devienne un dépôt d'organisation sans casser les docker pull existants, on convertit le compte personnel en organisation et on désigne un propriétaire.

Depuis le 26 août 2024, cette conversion transférait aussi les jetons d'accès personnels (PAT) du compte converti vers ce propriétaire. Elle le faisait en changeant l'enregistrement du propriétaire du jeton, sans en renouveler ni en révoquer le secret. Le propriétaire désigné n'était ni invité à confirmer, ni prévenu. D'où le scénario :

  1. L'attaquant crée un compte et y génère un jeton d'accès personnel.
  2. Il convertit ce compte en organisation et nomme sa victime propriétaire.
  3. Le jeton passe à la victime ; l'attaquant en conserve le secret, et le jeton reste actif avec le périmètre de la victime.
  4. Ce jeton s'authentifie auprès du registre comme la victime.

Ce que le jeton permettait

Dans les limites de son périmètre, il permettait de tirer, publier et supprimer des images dans les dépôts de la victime et dans ceux des organisations où elle a accès. Publier sous un nom légitime est un risque de chaîne d'approvisionnement, d'où la note critique.

Ce qu'il ne permettait pas : entrer dans l'interface web, changer le mot de passe, l'adresse e-mail ou la double authentification, ni prendre le compte.

Ce que Docker a vérifié

Docker a recensé toutes les conversions depuis le 26 août 2024 et les a recoupées avec les journaux d'authentification du registre, les données d'usage et les enregistrements de jetons.

Conclusion : aucune exploitation constatée. Mais les journaux montrent quand un jeton sert, pas qu'il existe : un jeton transféré et jamais utilisé ne laisse aucune trace. Docker a donc traité tous les jetons transférés pendant la fenêtre comme potentiellement exposés.

Chronologie (heure de la côte Est)

Comment s'y prendre

Docker dit aussi corriger le défaut de fond : accord exigé avant qu'un compte soit nommé propriétaire d'une organisation (avec notification), historique auditable de chaque changement de propriétaire de jeton, et revue des autres flux qui changent la propriété d'un identifiant.

Source : Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions, Docker, 12 octobre 2026.