Docker Hub: un bug IAM ha esposto 304.000 push a rischio impersonazione per 26

Una vulnerabilità critica in Docker Hub, resa pubblica il 12 ottobre 2026, ha consentito a un attaccante di impersonare utenti legittimi e manipolarne le immagini container sfruttando un flusso di business apparentemente innocuo: la conversione di account personali in organizzazioni. La finestra di esposizione si estende dal 26 agosto 2024 al 30 settembre 2026. Docker ha corretto il difetto in meno di quattro ore dal report, ma i token esposti restano un problema di supply chain potenzialmente invisibile nei log.

Il meccanismo del "silent token migration"

Il difetto di progettazione si annidava nel flusso di conversione account su Docker Hub. Secondo l'advisory ufficiale del vendor, la procedura seguiva tre passaggi deterministici: l'attaccante creava un account e generava un personal access token; convertiva l'account in organizzazione nominando come owner l'utente target; il sistema riassegnava automaticamente il PAT al nuovo owner senza invalidare il secret crittografico.

Docker ha documentato la conseguenza con precisione tecnica: "Within the scope of the token, a re-assigned PAT acted as the target user at the registry level, meaning an attacker could potentially pull, push, and/or delete images in the target's repositories and in organizations where the target had access". L'attaccante conservava il secret originale, mentre il token acquisiva la visibilità e i permessi dell'utente impersonato.

Il difetto non riguardava un errore di implementazione crittografica, ma una scelta architetturale: l'assenza di rotazione del secret e di meccanismo di consenso da parte dell'utente target. La riassegnazione avveniva a livello database, invisibile all'interfaccia utente e inizialmente non tracciata in log di audit dedicati.

Limiti del perimetro di attacco e classificazione del rischio

La vulnerabilità presentava confini definiti. Non permetteva accesso all'interfaccia web di Docker Hub, né modifiche a password, indirizzo email o configurazione del two-factor authentication. L'impersonazione operava esclusivamente a livello registry API, il che limitava le azioni possibili alle operazioni su immagini container ma escludeva il takeover completo dell'account.

Docker ha giustificato la classificazione critica con un rationale specifico: "Because that includes publishing images under a legitimate name, we treated this as a software supply chain risk and rated it critical". La capacità di pubblicare immagini sotto un nome legittimo rappresenta infatti un vettore di attacco alla supply chain: un'immagine compromessa con firma apparentemente valida può propagarsi nei pipeline CI/CD e nei deployment di produzione prima che qualsiasi controllo di integrità ne rilevi la compromissione.

"registry logs show when a token is used, not that it exists, so a transferred token that was never used leaves no trace"

Timeline e risposta dell'incidente

La scoperta e la gestione dell'incidente seguono una cronologia documentata con granularità oraria. Il report da parte dei ricercatori Peter Molnar e Krisztian Hozak, affiliati a mptrdev.com, è stato ricevuto il 30 settembre 2026 alle 11:40 AM. Docker ha deployato il fix in produzione alle circa 3:10 PM dello stesso giorno: un intervallo inferiore a quattro ore tra notifica e correzione.

Il write-up tecnico dei ricercatori è disponibile su ghostpat.com. Il contenuto specifico di quella pubblicazione non risulta riprodotto nelle fonti disponibili, quindi non è possibile verificare se contenga dettagli di exploit aggiuntivi rispetto all'advisory ufficiale.

Dopo il fix immediato — la rimozione completa del trasferimento PAT durante la conversione account — Docker ha implementato una sequenza di misure di contenimento. La notifica agli utenti esposti è stata inviata il 2 ottobre 2026 alle 5:30 PM EST. La deattivazione forzata dei PAT trasferiti è avvenuta l'8 ottobre 2026 alle 3:45 PM EST, con possibilità di opt-out per casi d'uso legittimi. Sono state inoltre introdotte la richiesta di consenso esplicito prima di nominare owner, il logging auditable dei cambi di ownership dei token e una review di altri flussi simili.

L'analisi dei 304.000 push e il problema dei token invisibili

Docker ha esaminato circa 304.000 push effettuati con token trasferiti durante i 26 mesi di finestra di esposizione. Il risultato dell'analisi: "Every push made with a transferred token landed either in the converted organization's own repositories or in the new owner's own repositories. None went into an unrelated user's or organization's account". L'affermazione "We found no evidence that the vulnerability was exploited" compare esplicitamente nell'advisory.

Parallelamente, Docker ha condotto analisi statica delle immagini pubbliche ad alto rischio, senza rilevare malware, cryptominer, infrastrutture di command and control, harvesting di credenziali o tampering.

Resta tuttavia un limite metodologico significativo, che Docker stesso ha dichiarato: i log di autenticazione del registry registrano quando un token viene utilizzato, non la sua esistenza. Un token trasferito e mai impiegato non lascia traccia nei log analizzabili. Questo vincolo introduce un'area di incertezza: non è possibile escludere che token inattivi siano stati generati e conservati per uso futuro, o che siano stati sfruttati in contesti non coperti dalla telemetria esaminata.

Cosa fare adesso

Per gli utenti e le organizzazioni che utilizzano Docker Hub, le azioni operative derivano direttamente dalle misure documentate da Docker nell'advisory:

• Verificare la propria casella di posta per eventuali notifiche di esposizione ricevute il 2 ottobre 2026; in assenza di notifica diretta, consultare lo stato dei propri PAT nell'account Docker Hub
• Controllare che i personal access token in uso siano stati generati personalmente e non siano stati oggetto di trasferimento ownership in seguito a conversione account o nomina in organizzazione
• Riesaminare le immagini pubblicate nelle proprie repository nel periodo 26 agosto 2024 - 30 settembre 2026, con particolare attenzione a quelle che non risultano associate a build automatizzate documentate
• Monitorare l'introduzione di logging auditable sui cambi di ownership dei token, funzionalità che Docker ha dichiarato di aver implementato post-incidente

Il brief non documenta raccomandazioni aggiuntive su rotazione preventiva di tutti i PAT, attivazione di controlli specifici o implementazione di policy di accesso: queste misure, sebbene prudenti, non risultano indicate esplicitamente dalla fonte primaria.

Pattern architetturale: quando il business logic diventa backdoor

L'incidente CVE-2026-105445 illustra una categoria di vulnerabilità spesso trascurata nei programmi di sicurezza: il design flaw in flussi di identity and access management che combinano operazioni legittime con effetti di sicurezza inattesi. La conversione account-personale→organizzazione è una funzionalità di prodotto standard; la riassegnazione automatica di credenziali senza rotazione del secret e un caso limite non contemplato nel threat modeling.

Il gap rileva un pattern più ampio: servizi che gestiscono transizioni di ownership su entità con capacità crittografiche autonome (token, chiavi API, service account) devono trattare la rotazione del secret come operazione obbligatoria, non ottimale. L'assenza di consenso dell'utente target ha inoltre rimosso un layer di difesa in profondità che molti framework IAM considerano standard.

Per le organizzazioni che operano registry o piattaforme di distribuzione software, il caso solleva questioni sui controlli interni: quanti altri flussi di business — merger di account, trasferimenti di repository, migrazioni di tenant — includono operazioni simili di riassegnazione credenziali senza invalidazione?

Docker ha indicato di aver avviato una review di "altri flussi simili". L'esito di quella review non risulta pubblicato nelle fonti disponibili.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://www.bleepingcomputer.com/news/security/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images/
• https://www.docker.com/blog/docker-hub-security-advisory-cve-2026-105445/
• https://blog.netmanageit.com/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images/
• https://daily.dev/posts/docker-hub-security-advisory-cve-2026-105445-ash3twcdv
• https://radar.offseq.com/threat/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images-11ce9d5cde15d8ed
• https://nvd.nist.gov/vuln/detail/CVE-2026-105445
• https://www.bleepingcomputer.com/news/security/docker-hub-flaw-let-attackers-impersonate-users-tamper-with-images/?ref=blog.netmanageit.com
• http://www.docker.com/blog/docker-hub-security-advisory-cve-2026-105445/