Cloudflare cancella i dischi dei container riutilizzati dopo una falla che esponeva dati tra tenant

Cloudflare ha corretto una vulnerabilità nell’isolamento dello storage di Cloudflare Containers che consentiva al workload di un cliente di recuperare frammenti di dati su disco lasciati da un altro tenant sulla stessa infrastruttura fisica.

La falla interessava anche Cloudflare Sandboxes, un servizio basato su Containers che consente di eseguire codice non attendibile, compresi i programmi generati dagli agenti AI. Il problema esponeva dati residui delle applicazioni, non storage attivo e collegato, ma i test hanno mostrato che i blocchi recuperabili erano distribuiti ampiamente nei sistemi di produzione esaminati.

Cloudflare ha applicato automaticamente le correzioni e completato la pulizia della propria infrastruttura il 19 settembre 2026. I clienti non devono intervenire.

I blocchi riciclati oltrepassavano il confine tra tenant

Cloudflare Containers esegue workload containerizzati per i clienti con account Workers Paid. Tra gli usi più comuni ci sono le applicazioni backend, i servizi di elaborazione dei processi e gli ambienti isolati per l’esecuzione del codice.

Cloudflare decide dove eseguire ciascun container, mentre più account cliente condividono i server e le risorse di storage del provider. Questo modello richiede una separazione rigorosa non solo tra i workload attivi, ma anche quando lo storage viene rilasciato e assegnato in seguito a un altro cliente.

Il ricercatore di sicurezza di Accomplish Oren Yomtov ha segnalato il problema il 4 settembre tramite il programma bug bounty di Cloudflare, identificato da BleepingComputer come HackerOne.

La vulnerabilità si manifestava quando un container veniva eliminato. I relativi blocchi fisici del disco tornavano in un pool condiviso, da cui potevano poi essere assegnati a container di account non collegati. Il pool era configurato in modo da non cancellare i blocchi prima del riutilizzo, anche se normalmente l’azzeramento era il comportamento predefinito.

Di conseguenza, assegnare un blocco a un nuovo tenant non garantiva che ogni byte fosse stato cancellato. Le parti non toccate dal nuovo workload potevano ancora contenere dati scritti dall’utente precedente.

Una scrittura da 4 KiB esponeva il resto di un blocco da 64 KiB

Lo storage interessato utilizzava il thin provisioning di Linux e allocava la capacità del disco in blocchi da 64 KiB. Il thin provisioning associa lo storage logico alla capacità fisica solo quando serve, evitando di riservare in anticipo un’intera allocazione su disco.

I ricercatori hanno dimostrato una conseguenza diretta della mancata corrispondenza tra dimensioni di allocazione e scrittura. Un container appena creato poteva scrivere 4 KiB in una regione del disco altrimenti inutilizzata e poi esaminare l’intero blocco fisico da 64 KiB tramite accesso al disco grezzo.

La nuova scrittura sovrascriveva i primi 4 KiB. I restanti 60 KiB potevano conservare dati di un container eliminato a cui era stato assegnato in precedenza lo stesso blocco fisico.

Non si trattava del normale accesso ai file tramite il filesystem montato di un altro tenant. L’attaccante esaminava invece lo storage recuperato al di sotto di quel livello, cercando strutture riconoscibili tra i byte rimasti.

Cloudflare ha dichiarato che uno sfruttamento riuscito avrebbe violato il confine di isolamento tra tenant. Tra i dati potenzialmente esposti:

• Metadati del filesystem e strutture delle directory
• Pagine di database e strutture complete di database SQLite
• Dati delle applicazioni
• Profili del browser Chromium
• File .env
• File contenenti credenziali

I risultati indicano che le informazioni sensibili non dovevano necessariamente trovarsi in un normale file completo per risultare utili. Pagine di database, frammenti di configurazione o voci di directory possono rivelare segreti e dettagli operativi anche se recuperati solo in parte.

I test in produzione hanno trovato residui nella maggior parte dei nodi esaminati

I ricercatori hanno rilevato materiale residuo in 18 delle 24 collocazioni dei container. Lo hanno inoltre trovato su 20 delle 22 macchine o nodi sottostanti inclusi nei test, distribuiti su quattro continenti, secondo quanto riportato in merito alla comunicazione di Cloudflare e ai risultati dei ricercatori.

Cloudflare ha riferito che i blocchi recuperati includevano strutture di directory, pagine di database e database SQLite strutturalmente completi. I ricercatori hanno inoltre individuato formati riconoscibili come profili di browser, file di ambiente e file contenenti credenziali.

Gli script di analisi hanno prodotto conteggi aggregati e verificato i formati dei dati, senza raccogliere il contenuto dei file. I ricercatori hanno dichiarato che la segnalazione inviata a Cloudflare non conteneva nomi, identificativi o credenziali di terzi, né contenuti recuperati appartenenti ai clienti. Il materiale eventualmente recuperato è rimasto riservato ed è stato eliminato in modo sicuro dopo la segnalazione.

Secondo Cloudflare, durante la verifica autorizzata non sono stati esposti dati reali dei clienti. Separatamente, i ricercatori hanno dichiarato di aver recuperato materiale residuo durante i test. Le due affermazioni descrivono aspetti diversi dell’attività: i test hanno dimostrato che le vecchie strutture di dati erano ancora accessibili, mentre i ricercatori affermano di aver evitato di conservare o inviare contenuti identificabili appartenenti a terzi.

La falla consentiva di divulgare dati, non di controllare altri workload

L’impatto dimostrato riguardava la riservatezza. I ricercatori non hanno mostrato che un attaccante potesse modificare i file attivi di un altro cliente, interrompere un servizio o assumere il controllo del container della vittima.

Il metodo, inoltre, non consentiva di leggere un disco mentre era ancora collegato attivamente a un altro workload. Lo sfruttamento dipendeva dal rilascio dei blocchi fisici e dal loro riciclo nel pool di storage condiviso.

Un attaccante non poteva nemmeno scegliere una vittima specifica. Cloudflare controllava la collocazione dei container e i blocchi riutilizzati disponibili per un nuovo workload dipendevano dalle decisioni di allocazione dell’infrastruttura. Un attaccante poteva quindi cercare dati residui, ma non richiedere storage assegnato in precedenza a una determinata organizzazione.

Questa limitazione riduce la precisione del metodo, ma non la sensibilità dei dati che si potrebbero recuperare. I segreti contenuti nei file .env, negli archivi di credenziali o nelle pagine di database potrebbero comunque avere valore, indipendentemente dal tenant che li aveva creati.

I ricercatori hanno inoltre riferito che Cloudflare Browser Run utilizzava la stessa configurazione del disco. La comunicazione di Cloudflare indicava Containers e Sandboxes, ma non menzionava Browser Run. Non è quindi chiaro se Cloudflare consideri Browser Run un servizio interessato separatamente o se la correzione abbia richiesto ulteriori interventi specifici per il servizio.

Cloudflare non ha trovato prove di sfruttamento oltre i test

Dopo aver riprodotto il problema, Cloudflare ha creato firme di rilevamento basate sulla proof of concept dei ricercatori e sui propri test. Ha quindi cercato nei registri conservati delle attività su disco eventuali comportamenti corrispondenti.

L’azienda ha trovato soltanto le attività autorizzate svolte dai ricercatori e dagli ingegneri di Cloudflare. Dall’analisi dei log, della telemetria e dei dati storici non sarebbero emerse prove che altri soggetti avessero usato la stessa tecnica per esporre dati dei clienti.

Le informazioni disponibili, tuttavia, non specificano quanto indietro nel tempo arrivassero i registri conservati. Cloudflare non ha neppure indicato quando sia stata introdotta la configurazione non sicura che non azzerava i blocchi. Non è quindi noto per quanto tempo sia stato possibile recuperare i blocchi residui.

Non sono stati pubblicati indicatori di compromissione che i clienti possano cercare nei propri sistemi. Poiché le prove rilevanti si trovavano nell’infrastruttura di storage e nei sistemi di collocazione di Cloudflare, i singoli utenti potrebbero avere una visibilità limitata sull’eventuale riassegnazione dei propri blocchi eliminati.

La correzione dell’allocazione era solo il primo passo

Cloudflare ha innanzitutto ripristinato l’azzeramento dei blocchi appena allocati. La modifica ha garantito che lo storage assegnato dopo la correzione venisse cancellato prima di poter essere usato da un altro tenant.

Il 14 settembre i ricercatori hanno confermato che la loro proof of concept non funzionava più. La modifica dei criteri di allocazione, però, non ha rimosso tutte le associazioni storiche già presenti sulla piattaforma.

Alcuni blocchi potevano rimanere associati ai dischi dei container in esecuzione. Anche i livelli delle immagini preparate e gli snapshot memorizzati nella cache potevano conservare associazioni più vecchie. Cloudflare ha quindi dismesso tutti i dischi dei container attivi e svuotato le cache interessate, drenando e riavviando i server nei periodi di minore attività.

L’azienda ha completato la pulizia il 19 settembre 2026. La correzione è stata applicata all’infrastruttura di Cloudflare: i clienti non devono aggiornare le applicazioni, ruotare le immagini dei container o modificare la configurazione per beneficiare della correzione.

Non sono stati pubblicati identificativi CVE né valutazioni formali della gravità. Il problema è più correttamente descritto come una violazione della riservatezza tra tenant che coinvolgeva dati residui potenzialmente sensibili, non come una compromissione dell’host o una fuga distruttiva dal container.

I ricercatori hanno descritto il caso come la loro sesta evasione da un sandbox di codice resa pubblica dal mese di luglio, dopo le ricerche su Claude Cowork e Claude Code di Anthropic, sullo strumento a riga di comando di Cursor, su Docker e su Codex di OpenAI. In questo caso, tuttavia, la capacità dimostrata consisteva nel recuperare contenuti di dischi riciclati, non nel controllare arbitrariamente un altro tenant o l’host di Cloudflare.