Docker Hub: il token ha cambiato proprietario, il segreto no

Un database può essere perfettamente coerente e un sistema di identità completamente sbagliato. Basta che un campo cambi proprietario senza che cambi anche chi possiede il segreto necessario a usarlo. È il genere di errore che supera i controlli di integrità, non provoca necessariamente un crash e, proprio per questo, può restare in produzione per anni. La vulnerabilità CVE-2026-105445, corretta da Docker Hub a fine settembre 2026, è un esempio quasi didattico di questa differenza.

La notizia non è soltanto che un token poteva autenticarsi come un altro utente. È come ci arrivava: attraverso una funzione amministrativa legittima, la conversione di un account personale in organizzazione. Nessuna magia da hacker e nessuna necessità di compromettere un server. Il problema stava nel significato attribuito a una transizione di stato. E quando il software distribuisce immagini usate da altre persone, una transizione sbagliata non resta confinata a una schermata di gestione.

La conversione di un account non è una semplice modifica anagrafica

Su Docker Hub un account personale può essere convertito in organizzazione, mantenendo il namespace dei repository: un riferimento come alice/app continua a funzionare anche se cambia il modello di proprietà. È una scelta ragionevole dal punto di vista operativo, perché evita di rompere riferimenti e automazioni già distribuiti. Ma proprio questa continuità rende la conversione un’operazione delicata: non cambia soltanto un’etichetta, cambiano i soggetti autorizzati a operare.

Secondo l’advisory ufficiale Docker del 12 ottobre 2026, dal 26 agosto 2024 il processo trasferiva anche i Personal Access Token (PAT) dell’account convertito al nuovo proprietario dell’organizzazione. La piattaforma aggiornava il record del proprietario del token, ma non revocava né ruotava il valore segreto. Inoltre l’utente designato come nuovo owner non doveva confermare l’operazione e non riceveva una notifica.

La conseguenza era netta: chi aveva generato e conservato il token prima della conversione continuava a conoscerne il valore, mentre il sistema lo trattava ormai come una credenziale del nuovo proprietario. I ricercatori Peter Molnar e Krisztian Hozak hanno documentato e riprodotto il comportamento con account di test consenzienti. È importante distinguere questa prova tecnica dalla presenza di abusi contro utenti reali: la prima è dimostrata, la seconda non è stata accertata.

Proprietà, possesso e autorizzazione sono tre cose diverse

Per capire l’errore bisogna separare tre concetti che spesso finiscono mescolati nel codice. La proprietà è ciò che dichiara il database: a quale utente appartiene il token. Il possesso è chi conosce materialmente la stringa segreta e può presentarla. L’autorizzazione è l’insieme delle operazioni che il sistema consente quando quella stringa viene presentata. Modificare la prima informazione non modifica automaticamente la seconda. E se la terza viene ricalcolata sulla base del nuovo owner, il problema diventa serio.

Nel caso Docker Hub, un soggetto poteva creare un account, generare un PAT e convertire quell’account in organizzazione indicando un altro utente come proprietario. Il PAT restava utilizzabile da chi lo aveva creato, ma si autenticava al registry con l’identità del destinatario. Entro gli scope del token e i permessi di quell’identità, poteva quindi consentire operazioni di lettura, pubblicazione o cancellazione di immagini nei repository accessibili al destinatario.

Questo non equivaleva a prendere il controllo dell’intero account Docker Hub: l’advisory precisa che non dava accesso all’interfaccia web e non permetteva di cambiare password, email o impostazioni del secondo fattore. Ridurre la vulnerabilità a un generico account takeover sarebbe quindi impreciso. Il perimetro reale era il registry, e proprio lì si trovano le operazioni da cui dipende la distribuzione del software.

Se un sistema trasferisce un’identità senza invalidare le credenziali già conosciute da altri, non sta trasferendo il controllo: sta distribuendo un’ambiguità con nuovi permessi.

Perché il problema arriva fino alla supply chain

Un’immagine container pubblicata sotto un namespace riconoscibile beneficia della fiducia che sviluppatori e pipeline attribuiscono a quel nome. Se una credenziale consente di pubblicare immagini come un utente legittimo, il rischio non è soltanto l’accesso a dati riservati: è la possibilità di modificare ciò che altri scaricheranno e distribuiranno. Docker ha per questo classificato il problema come critico e come rischio per la software supply chain.

Qui emerge una distinzione che vale anche oltre Docker. Controllare che una dipendenza abbia una versione precisa non basta a stabilire chi l’abbia pubblicata e con quali credenziali. Lo stesso vale per checksum e lockfile: sono garanzie diverse, non sinonimi. È un tema che ho già affrontato parlando di integrità delle dipendenze e limiti del lockfile. La catena di fiducia parte prima del file scaricato, nel processo che autorizza qualcuno a produrlo.

L’errore è interessante anche perché non richiedeva un bypass della normale autenticazione del registry. La richiesta poteva apparire valida: il token era attivo e associato, nei dati del sistema, a un proprietario autorizzato. È lo stesso paradosso di molte architetture di sicurezza: ogni controllo locale passa, ma l’invariante complessivo è già stato violato. Un controllo che verifica soltanto se un token è valido non può accorgersi, da solo, che quel token è stato consegnato a un soggetto diverso da quello che ora rappresenta.

I log possono escludere un abuso osservato, non cancellare un’esposizione

Docker ha corretto la vulnerabilità il 30 settembre 2026, meno di quattro ore dopo la segnalazione, e ha notificato gli utenti potenzialmente interessati il 2 ottobre. L’8 ottobre ha disattivato i PAT trasferiti durante le conversioni, con eccezioni per i titolari che avevano richiesto di mantenerli. Ha inoltre esaminato le conversioni avvenute nella finestra interessata e circa 304.000 operazioni di push effettuate con token trasferiti.

L’azienda dichiara di non aver trovato evidenze di sfruttamento. È un’informazione importante, ma non significa che ogni token rimasto nelle mani di terzi sia stato necessariamente usato o che sia possibile dimostrare l’assenza assoluta di ogni rischio. La stessa Docker chiarisce il limite: i log registrano l’utilizzo di un token, non la sua mera esistenza nelle mani di qualcuno. Un segreto trasferito e mai presentato al registry non lascia una traccia d’uso. Per questo l’intervento ha riguardato tutti i token trasferiti nel periodo, non soltanto quelli con attività sospetta.

Il punto metodologico è semplice: un’indagine forense misura ciò che gli strumenti sono in grado di osservare. Non va svalutata, ma nemmeno trasformata in una certificazione universale. È una distinzione vicina a quella tra certificato tecnicamente valido e identità effettivamente affidabile, che ho discusso in un altro caso di fiducia costruita su premesse sbagliate.

La lezione progettuale: definire gli invarianti prima del pulsante “Converti”

Non serve trasformare ogni operazione amministrativa in una cerimonia. Serve però riconoscere quelle che cambiano un confine di fiducia. Se una migrazione sposta ownership, ruoli o permessi, il sistema dovrebbe rendere espliciti almeno quattro vincoli: il destinatario deve conoscere e accettare il cambiamento; i segreti precedenti non devono acquisire poteri nuovi per effetto collaterale; la transizione deve essere tracciabile; un rollback o una revoca devono avere una semantica prevedibile.

In pratica, la migrazione di una credenziale dovrebbe essere progettata come un cambio di autorità, non come un aggiornamento di foreign key. La strategia più prudente, quando cambia il soggetto che controlla un’identità, è invalidare le vecchie credenziali e farne emettere di nuove dal nuovo titolare. Per le automazioni di organizzazione, è preferibile usare credenziali dell’organizzazione anziché PAT personali, come raccomanda Docker. Così proprietà amministrativa e responsabilità operativa rimangono più vicine.

Il fix immediato di Docker ha infatti eliminato il trasferimento automatico dei PAT durante la conversione. L’azienda ha annunciato anche l’introduzione del consenso prima della nomina a proprietario, la notifica del cambiamento e una cronologia verificabile dei passaggi di ownership. Sono interventi che riguardano il modello del processo, non soltanto una condizione aggiunta a un endpoint.

Un sistema coerente non è necessariamente un sistema sicuro

CVE-2026-105445 non insegna che Docker sia intrinsecamente inaffidabile, né che ogni conversione di account sia pericolosa. Mostra qualcosa di più utile per chi progetta software: un flusso può essere tecnicamente corretto, rispettare i vincoli del database e produrre comunque un’autorizzazione che nessuno aveva davvero concesso. La vulnerabilità nasce quando il significato di una relazione cambia, ma le credenziali sopravvivono come se nulla fosse successo.

Per questo, nei sistemi che gestiscono identità e automazioni, la domanda non può essere soltanto “il record è stato aggiornato?”. Deve diventare “chi può ancora usare ciò che abbiamo appena trasferito?”. È una domanda meno comoda da implementare. Ed è precisamente quella che evita di confondere una modifica riuscita con un processo sotto controllo.