Cloudflare ha reso pubblici i dettagli di una vulnerabilità, scoperta e corretta a inizio settembre 2026, che per un periodo limitato ha permesso a un cliente di leggere frammenti di dati appartenenti ad altri clienti sulla stessa infrastruttura condivisa di Cloudflare Containers. Non risultano sfruttamenti malevoli, ma il meccanismo tecnico e la trasparenza con cui Cloudflare lo ha raccontato meritano attenzione da parte di chiunque costruisca la propria infrastruttura su cloud multi-tenant, italiano o globale che sia.

I fatti verificati

  • Componente colpito: Cloudflare Containers, il servizio che esegue carichi di lavoro containerizzati sull'infrastruttura edge di Cloudflare, disponibile per gli account Workers Paid.
  • Causa tecnica: il sistema di storage usava il thin provisioning di Linux device mapper con l'opzione skip_block_zeroing attiva. Quando un container veniva eliminato, i suoi blocchi da 64 KiB tornavano in un pool condiviso senza essere azzerati. Un nuovo container che scriveva un blocco solo parzialmente poteva ritrovarsi a leggere, nella porzione non sovrascritta, dati residui del cliente precedente.
  • Scoperta: il ricercatore Oren Yomtov (Accomplish) ha individuato il problema il 4 settembre 2026 tramite il programma di bug bounty di Cloudflare su HackerOne, dimostrandolo con un proof of concept controllato.
  • Cosa è stato recuperato nel test: 2.700 inode di directory estranee, oltre a pagine di database e intere strutture SQLite riconoscibili tramite analisi dei checksum ext4.
  • Portata: il problema riguardava più host su quattro continenti; per la natura del posizionamento automatico dei workload, un attaccante non poteva scegliere una vittima specifica né un host particolare.
  • Sfruttamento reale: Cloudflare dichiara di non aver trovato, analizzando la telemetria storica degli I/O su disco, alcuna evidenza di accessi diversi da quelli del ricercatore e dei propri ingegneri.
  • Tempistica della correzione: segnalato e risolto lo stesso giorno (4 settembre); rollout completato il 7 settembre; pulizia di tutte le snapshot cache pre-esistenti conclusa il 19 settembre.

Perché conta anche per chi non usa Cloudflare Containers

Il caso specifico è stato gestito bene: divulgazione responsabile, correzione in giornata, nessuna prova di abuso, resoconto tecnico pubblico dettagliato. Ma il meccanismo che lo ha reso possibile, il riutilizzo di spazio disco senza azzeramento completo tra un tenant e l'altro, è una classe di problema che riguarda qualunque infrastruttura condivisa: container, macchine virtuali, storage a blocchi, persino dispositivi di rete condivisi in ufficio. La domanda che ogni azienda dovrebbe farsi non è "useremo mai Cloudflare Containers", ma "il nostro fornitore cloud azzera davvero lo storage riciclato tra un cliente e l'altro, e come lo verifichiamo?".

Cosa significa per le aziende italiane

  • Dipendenza dal cloud e responsabilità del titolare: sempre più aziende italiane costruiscono applicazioni su Cloudflare Workers e Containers per motivi di prestazioni e costi. Il GDPR, all'art. 28, rende il cliente, in quanto titolare del trattamento, responsabile della scelta e della vigilanza sul fornitore cloud che agisce come responsabile del trattamento: il fatto che il fornitore dichiari che va tutto bene non esime dal dovere di valutare autonomamente il rischio.
  • La valutazione del rischio spetta a chi tratta i dati, non solo al fornitore: anche se Cloudflare non ha trovato prove di sfruttamento malevolo, le aziende che gestiscono dati personali tramite Workers Paid dovrebbero comunque documentare la propria valutazione interna del rischio, perché in caso di controllo l'onere della prova è del titolare.
  • Catena di fornitura sotto NIS2: per i soggetti essenziali o importanti secondo NIS2, la gestione del rischio di catena di approvvigionamento (art. 21) impone di considerare esplicitamente eventi come questo nella valutazione dei fornitori cloud critici, anche quando l'incidente è stato contenuto e comunicato in modo trasparente.
  • Un esempio da citare, non da temere: la vicenda dimostra anche il valore dei programmi di bug bounty. Le aziende italiane che gestiscono infrastrutture critiche possono trarne un modello concreto: premiare la divulgazione responsabile costa molto meno di una violazione scoperta per prima da un attaccante.

Cosa fare subito

  • Se si utilizzano Cloudflare Workers o Containers su piano Paid, verificare le comunicazioni ufficiali ricevute da Cloudflare relative a questo incidente.
  • Ruotare in via precauzionale le chiavi API, i token e i segreti gestiti da workload containerizzati attivi tra il 4 e il 19 settembre 2026, come suggerito dalla stessa Cloudflare.
  • Documentare la valutazione del rischio relativa a questo evento nel registro dei trattamenti o nella documentazione di gestione del rischio, anche in assenza di evidenze di compromissione.
  • Includere nella due diligence dei fornitori cloud una domanda specifica su come viene gestito l'azzeramento dello storage riciclato tra tenant diversi.
  • Per i soggetti NIS2, aggiornare la mappatura dei fornitori critici includendo questo tipo di rischio nella prossima revisione della gestione del rischio di catena di fornitura.