In breve
Un’impostazione dello storage di Cloudflare Containers evitava di azzerare i blocchi disco riutilizzati: un nuovo container poteva così leggere frammenti lasciati dal container eliminato di un altro cliente. Cloudflare l’ha risolta in pochi giorni, non ha trovato segni di abuso e non richiede interventi ai clienti. Se eseguite carichi di lavoro su Cloudflare Workers e sul suo runtime per container, il messaggio pratico è semplice: un disco eliminato non è mai davvero vuoto per definizione.
Considerate ogni disco cloud condiviso come non affidabile dal momento in cui lo rilasciate, e non salvateci segreti fin dall’inizio.
Che cosa ha comunicato Cloudflare?
Il 24 settembre 2026 Cloudflare ha pubblicato un post-mortem su un’esposizione di dati tra tenant in Containers, il runtime per container affiancato a Workers, e in Sandboxes, che esegue codice non attendibile come i task degli agenti IA. Secondo l’azienda, un cliente Workers Paid avrebbe potuto recuperare dati residui da blocchi di storage usati in precedenza dai container di altri clienti sullo stesso host.
Il ricercatore di sicurezza Oren Yomtov di Accomplish ha segnalato il problema tramite il programma HackerOne di Cloudflare il 4 settembre alle 15:26 UTC. Cloudflare lo ha confermato in produzione circa tre ore dopo e in serata ha integrato un fix del runtime. BleepingComputer e The Hacker News hanno ripreso la notizia nei giorni successivi.
Secondo Cloudflare, i blocchi recuperati contenevano strutture di directory, pagine di database e database SQLite strutturalmente completi. Il resoconto dei ricercatori, come riportato da entrambe le testate, cita anche profili del browser Chromium, file .env e file di credenziali. I ricercatori sostengono che i loro script restituivano solo conteggi aggregati, non il contenuto dei file.
Come passavano i dati da un cliente all’altro?
I dischi dei container venivano ricavati da un pool condiviso tramite il thin provisioning del device-mapper di Linux. Nel pool era attiva l’opzione skip_block_zeroing, che indica al kernel di non azzerare un blocco appena allocato prima di assegnarlo. I blocchi erano da 64 KiB. Quando un nuovo container scriveva solo pochi kilobyte in un blocco appena assegnato, il resto conteneva ancora ciò che vi aveva scritto il proprietario precedente.
Rinunciare all’azzeramento è un compromesso di prestazioni diffuso, perché cancellare ogni blocco costa I/O. È sicuro quando il pool appartiene a un solo tenant, pericoloso quando è condiviso da molti. Il fix di Cloudflare ha rimosso l’opzione, dismesso tutti i dischi dei container creati prima della mitigazione, svuotato gli snapshot delle immagini in cache e drenato e riavviato gli host nelle ore di minor traffico.
Due limiti riducevano il rischio: un attaccante non poteva scegliere la vittima né leggere un disco ancora collegato a un container in esecuzione. Poteva uscire soltanto ciò che era rimasto per caso sullo spazio rilasciato.
Che cosa cambia per i team software?
Primo: su un’infrastruttura condivisa «eliminato» non significa «cancellato». È la stessa classe di bug dei dati residui nei volumi cloud riutilizzati o nella memoria GPU, e si ripresenterà con altri fornitori. Il vostro threat model per qualsiasi piattaforma multi-tenant, compresi i prodotti Cloudflare più recenti, deve dare per scontato che lo storage rilasciato possa essere letto da altri.
Secondo: le sandbox per agenti IA alzano la posta. I team eseguono sempre più spesso codice generato da agenti, sessioni di browser e database temporanei in container effimeri. Sono proprio i dati esposti da questo bug: profili del browser, file SQLite locali e file .env con chiavi API. Effimero non vuol dire a basso rischio se il disco sopravvive al container.
Terzo: la compliance dipende comunque dai vostri controlli. Poiché Cloudflare non ha rilevato abusi, per la maggior parte dei clienti non si tratta di una violazione da notificare. Ma ai sensi del GDPR, di HIPAA o di SOC 2 dovete poter dimostrare che dati personali e credenziali restano protetti anche se l’isolamento del fornitore fallisce. Crittografia a livello applicativo e credenziali a breve scadenza sono ciò che vi permette di farlo.
Che cosa significa per il mercato italiano?
In Italia l’isolamento tra tenant pesa soprattutto negli acquisti cloud della Pubblica Amministrazione e dei settori regolati: i servizi cloud destinati alla PA devono essere qualificati dall’Agenzia per la Cybersicurezza Nazionale (ACN), e con il recepimento della direttiva NIS2 un numero crescente di aziende private deve dimostrare di gestire il rischio della catena di fornitura. Il caso Cloudflare mostra che una scelta di performance nello storage può aggirare le garanzie di separazione senza che nessun processo appaia difettoso.
Sul fronte privacy, il GDPR chiede al titolare di documentare ogni potenziale violazione nel proprio registro, anche quando non serve la notifica al Garante per la protezione dei dati personali ai sensi dell’articolo 33. Annotate quindi la valutazione di questo incidente, verificate se sui container interessati c’erano dati personali o credenziali e inserite la cancellazione sicura dei dischi rilasciati negli accordi con i responsabili del trattamento. Per le PMI che stanno introducendo agenti IA in sandbox è spesso l’intervento più rapido da chiudere prima di un audit.
Che cosa fare adesso?
- Non serve alcuna patch d’emergenza. Cloudflare ha applicato il fix su tutta la piattaforma; da parte vostra non c’è nulla da aggiornare.
- Fate l’inventario di ciò che i container scrivono su disco. Elencate i carichi Containers o Sandboxes che salvano database, profili del browser, token in cache o file
.envsul disco di root. - Ruotate per precauzione i segreti a lunga durata. Se un container era in esecuzione prima del 7 settembre 2026 con chiavi API o password di database su disco, ruotarle è un’assicurazione a basso costo.
- Tenete i segreti fuori dal file system. Iniettate le credenziali a runtime da un secrets manager con TTL brevi, invece di includerle nelle immagini o scriverle su disco.
- Cifrate i dati temporanei sensibili. Per i carichi che devono scrivere localmente dati personali o finanziari, cifrateli con una chiave per singolo carico: i blocchi residui diventano inutili per chiunque altro.
Domande frequenti
Qual era la vulnerabilità di Cloudflare Containers?
Cloudflare Containers e Sandboxes archiviavano i dischi dei container in un pool condiviso in thin provisioning, configurato per non azzerare i blocchi da 64 KiB riutilizzati. Quando il container di un cliente veniva eliminato, i suoi blocchi tornavano nel pool senza essere cancellati, e un nuovo container di un altro cliente Workers Paid sullo stesso host poteva leggere i dati rimasti.
Sono stati rubati dati dei clienti?
Cloudflare afferma di non aver trovato prove di sfruttamento malevolo nella telemetria di I/O disco disponibile; l’unica attività osservata proveniva dai ricercatori e dai propri ingegneri. I ricercatori dichiarano che i loro script restituivano conteggi aggregati e non il contenuto dei file. Inoltre un attaccante non poteva scegliere la vittima né leggere un disco ancora collegato a un container attivo.
I clienti Cloudflare devono fare qualcosa?
No. Secondo Cloudflare la vulnerabilità è corretta e la bonifica non richiede interventi dei clienti. I team che conservavano segreti a lunga durata o database sensibili sui dischi dei container possono comunque ruotare quelle credenziali per precauzione.
Quando è stata segnalata e corretta la falla?
Oren Yomtov di Accomplish l’ha segnalata tramite HackerOne il 4 settembre 2026. Cloudflare ha integrato un fix del runtime lo stesso giorno, ha concluso il rollout il 7 settembre, ha completato la pulizia degli snapshot il 19 settembre e ha pubblicato la divulgazione il 24 settembre 2026.
Bisogna notificare il Garante privacy?
Per la maggior parte dei clienti no: Cloudflare non ha rilevato abusi e non richiede interventi. Resta consigliabile documentare la valutazione dell’incidente nel registro delle violazioni e verificare se sui container interessati si trovavano dati personali o credenziali.
Fonti
Cloudflare Blog — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (24 settembre 2026)
BleepingComputer — Cloudflare fixes Containers cross-tenant flaw exposing customer data
The Hacker News — Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data