Archives par mot-clé : chaîne d’approvisionnement logicielle

Ghostpat, la faille qui exposait les images Docker

Une faille critique de Docker Hub permettait d’utiliser les droits d’un autre utilisateur pour manipuler ses images de conteneurs, avec un risque pour la chaîne d’approvisionnement logicielle.

Identifiée sous la référence CVE-2026-105445, la vulnérabilité GhostPat touchait la conversion des comptes personnels Docker Hub en organisations. Un jeton d’accès conservé par un attaquant pouvait être réattribué à un autre utilisateur, donnant accès aux dépôts autorisés pour cette victime. Découverte par Peter Molnar et Krisztian Hozak, cette erreur de gestion des identités a reçu un score de gravité de 9,4 sur 10. Présente pendant plus de deux ans, elle pouvait permettre la publication d’images malveillantes sous une identité légitime.

Un jeton personnel pouvait changer d’identité

Le problème se trouvait dans une opération administrative de Docker Hub. Un utilisateur pouvait transformer son compte personnel en organisation et désigner un autre utilisateur comme propriétaire. Cette transition entraînait également le transfert des jetons d’accès personnels, les PAT, vers le propriétaire choisi.

Or, ce transfert ne s’accompagnait pas d’un renouvellement du secret permettant d’utiliser ces jetons. Leur ancien détenteur conservait donc une information toujours valide. Le nouveau propriétaire, lui, n’avait pas à donner son accord pour cette réattribution. Une opération de gestion de compte devenait ainsi une rupture dans le contrôle des accès.

Un attaquant pouvait exploiter cette combinaison en faisant rattacher à sa victime un jeton dont il connaissait déjà le secret. Docker Hub reconnaissait ensuite ce jeton comme appartenant à l’utilisateur ciblé. L’identité associée à l’accès avait changé, sans que la personne capable de l’utiliser ait perdu cette capacité.

Les conséquences dépendaient de deux éléments, les permissions du jeton et les droits de la victime. Selon leur combinaison, l’attaquant pouvait récupérer des images, en publier ou en supprimer. Le périmètre concernait les dépôts personnels accessibles à l’utilisateur ciblé, ainsi que ceux des organisations auxquelles celui-ci avait accès. La fiche CVE confirme cette possibilité d’agir sur les images au niveau du registre.

La menace dépassait donc la simple consultation non autorisée. Publier une image sous le nom d’un développeur légitime pouvait introduire du contenu malveillant dans une chaîne d’approvisionnement logicielle. L’image aurait été distribuée depuis un emplacement associé à un acteur réel, alors que son contenu pouvait avoir été modifié par un tiers.

Cette possibilité explique la qualification critique de GhostPat. Elle ne signifiait toutefois pas que toutes les fonctions du compte devenaient accessibles. La faille ne permettait pas de se connecter à l’interface web de Docker Hub, de changer le mot de passe, de modifier l’adresse électronique ou de toucher aux paramètres de double authentification. Le risque portait sur les opérations du registre autorisées par le jeton, avec des conséquences potentiellement importantes pour les images concernées.

Une enquête sur deux ans de transferts

Peter Molnar et Krisztian Hozak ont découvert cette vulnérabilité, baptisée GhostPat. Le défaut était resté présent dans le code pendant plus de deux ans. Cette durée imposait de vérifier rétrospectivement les conversions de comptes et les usages des jetons transférés.

Docker affirme avoir examiné l’ensemble de ces conversions sur la période concernée. L’entreprise a également étudié environ 304 000 publications d’images réalisées avec les jetons issus de ce mécanisme. Ce chiffre correspond à des opérations de dépôt dans le registre, et ne constitue pas un décompte d’images compromises ou d’attaques.

Les vérifications ont aussi porté sur les images publiques considérées comme les plus exposées à une éventuelle compromission. Selon Docker, ces investigations n’ont révélé aucun indice d’exploitation de GhostPat. Ce constat doit conserver son attribution, il s’agit du résultat communiqué par l’entreprise à l’issue de ses recherches, et non de la preuve qu’une attaque a eu lieu.

Au début d’octobre 2026, Docker a averti les utilisateurs dont les comptes avaient reçu des jetons provenant d’autres comptes. Les propriétaires des organisations correspondantes ont également été informés. L’enjeu était de permettre aux personnes concernées d’identifier ces accès et d’en vérifier la légitimité.

Le 8 octobre, les jetons potentiellement dangereux ont été désactivés. Une exception a été appliquée à ceux pour lesquels les titulaires avaient expressément demandé le maintien en activité. Docker recommande aux utilisateurs avertis d’examiner leurs jetons personnels et de révoquer ceux qu’ils ne reconnaissent pas ou dont ils n’ont plus besoin.