Una flaw in Docker Hub permetteva ai token di agire come altri utenti
Una flaw in Docker Hub consentiva ai personal access tokens di agire come un altro utente nel container registry, dando al titolare del token la possibilità di push, pull o delete immagini entro i permessi dell'account interessato. Docker ha corretto il problema il 30 settembre e ha dichiarato di non aver trovato prove che la vulnerabilità sia stata sfruttata.
Docker Hub è il registry usato per pubblicare e scaricare container images, componenti software impacchettati comunemente usati da team di sviluppo, provider di hosting e servizi cloud. Docker ha dichiarato che il problema era nel processo che converte un account personale in un'organizzazione. Durante quella conversione, i personal access tokens, spesso abbreviati in PAT, venivano trasferiti all'account indicato come nuovo proprietario dell'organizzazione. Un PAT è un segreto usato al posto di una password quando il software si connette al registry, e Docker ha dichiarato che la persona che aveva originariamente creato ciascun token poteva ancora usarlo.
Il problema era limitato all'accesso al registry. Docker ha dichiarato che non dava accesso all'interfaccia web di Docker Hub e non poteva essere usato per cambiare la password di un account, l'indirizzo email o le impostazioni di two-factor authentication. Inoltre non poteva essere usato per prendere il controllo di un account tramite quelle impostazioni web. L'impatto era comunque serio perché un token trasferito poteva funzionare come il proprietario indicato nel registry, a seconda del livello di permesso del token.
Docker traccia la vulnerabilità come CVE-2026-105445 e l'ha classificata critica. Il record CVE pubblicato il 13 ottobre le assegna un punteggio CVSS 4.0 di 9.4. Docker ha dichiarato che la flaw è esistita dal 26 agosto 2024 fino alla correzione, un periodo di poco più di due anni. La correzione è stata applicata direttamente a Docker Hub, quindi gli utenti non devono installare un aggiornamento software per ricevere la correzione lato piattaforma.
I meccanismi sono importanti per qualsiasi team che si affidi a container images nelle pipeline di build o deployment. Docker Hub non sposta un repository da un account a un altro. Invece, un utente può convertire un account personale in un'organizzazione che mantiene lo stesso nome, indicando un account esistente come proprietario. Mentre la flaw era presente, quella conversione cambiava il proprietario registrato per ciascun PAT ma lasciava il segreto invariato. In termini pratici, un token creato da una persona poteva essere accettato dal registry come se appartenesse al nuovo proprietario indicato.
Docker e i ricercatori che hanno segnalato la flaw hanno detto che al proprietario indicato non veniva chiesto di approvare la modifica e non veniva notificato. La pagina di conversione di Docker includeva almeno dall'agosto 2024 una formulazione secondo cui il nuovo proprietario riceve un'email di notifica. I ricercatori, di mptrdev.com, hanno chiamato il problema GhostPat e hanno detto nel loro write-up tecnico di averlo riprodotto due volte usando account di test consenzienti. Hanno detto di essere riusciti ad accedere al registry come account target, creare e fare push verso un repository in quel namespace, fare push verso un'organizzazione a cui il target apparteneva e fare pull di repository privati.
Le azioni possibili dipendevano dai permessi del token trasferito. Entro quei limiti, poteva pull images, push images o delete images in repository di proprietà dell'utente indicato e in organizzazioni a cui quell'utente poteva accedere. Docker ha dichiarato di aver considerato la flaw critica perché l'accesso poteva includere la pubblicazione di immagini sotto un nome legittimo. Questo rischio è significativo per i team che gestiscono siti web e infrastrutture, perché le container images spesso alimentano sistemi di deployment automatizzato, e un nome di repository fidato può avere peso operativo.
Docker ha anche richiamato incidenti separati avvenuti a marzo e aprile, in cui gli attaccanti hanno usato credenziali di publisher rubate per fare push di immagini Trivy malevole e immagini KICS malevole nei repository Docker Hub degli stessi publisher. Questi incidenti non sono descritti come sfruttamento di questa vulnerabilità, ma mostrano perché le credenziali del registry e i nomi di immagini fidati sono asset di sicurezza sensibili.
Docker ha dichiarato di aver esaminato ogni conversione di account effettuata durante il periodo interessato e di aver confrontato le conversioni con i log del registry e i record dei token. L'azienda ha cercato token usati sotto più di un'identità ed esaminato ogni push effettuato con un token trasferito, circa 304.000 push in totale. Docker ha dichiarato di non aver trovato prove che la vulnerabilità sia stata sfruttata.
Secondo Docker, ogni push esaminato è andato a un repository appartenente all'organizzazione convertita oppure al suo proprietario indicato. Nella maggior parte dei casi, Docker ha detto che entrambi gli account sembravano appartenere alla stessa persona o allo stesso team. Dove Docker non ha potuto confermare che una sola persona controllasse entrambi gli account, ha analizzato le immagini pubbliche a rischio più elevato senza eseguirle e ha dichiarato di non aver trovato malware o tampering.
C'è un limite importante a questa revisione. Docker ha detto che i log del registry mostrano quando un token viene usato, non semplicemente che esiste. Un token trasferito che non è mai stato usato non comparirebbe in quei log. Per questo motivo, Docker ha trattato ogni token trasferito da una conversione durante il periodo interessato come potenzialmente coinvolto, che fosse stato usato o meno. L'advisory di Docker riporta i risultati per i push, ma non afferma cosa l'azienda abbia trovato per pull o deletion effettuati con token trasferiti, inclusi pull da repository privati.
Il 2 ottobre, Docker ha inviato email agli utenti i cui account avevano ricevuto token trasferiti e, separatamente, ai proprietari delle organizzazioni coinvolte. Le email elencavano i token rilevanti per descrizione e data di creazione. Docker non ha dichiarato quanti utenti o token fossero inclusi, descrivendo il gruppo interessato solo come un numero limitato di utenti. Docker ha detto che chi non ha ricevuto l'email non è stato esposto e non deve fare nulla.
Docker ha disattivato i token trasferiti che aveva identificato l'8 ottobre. I token che i proprietari avevano chiesto di mantenere non sono stati disattivati. Un publisher del linter Docker Compose compose-lint ha scritto di aver ricevuto due email il 2 ottobre, una come proprietario di un'organizzazione e una per il suo account utente. Ha detto di aver ruotato due token di continuous integration e controllato le firme su 42 immagini pubblicate, tracciando ogni immagine fino alla build run che l'aveva creata.
Docker consiglia agli utenti di rivedere i propri personal access tokens, revocare quelli che non riconoscono o non usano più, e usare organization access tokens per l'automazione che appartiene a un'organizzazione invece del PAT di una singola persona. In Docker Hub, gli utenti possono aprire Account settings e poi Personal access tokens per vedere quando ciascun token è stato creato e quando è stato usato l'ultima volta. I ricercatori hanno anche suggerito di fare attenzione a un token che l'utente non ha creato, indipendentemente dalla sua descrizione, e alla comparsa di un'organizzazione sconosciuta nell'account switcher.
Gli organization access tokens richiedono un abbonamento Docker Team o Docker Business. Docker dice che sono gestiti da un proprietario dell'organizzazione, un proprietario dell'azienda o un ruolo personalizzato con quel permesso, e che non funzionano con Docker Desktop o Image Access Management.