Cloudflare heeft een kwetsbaarheid verholpen in Cloudflare Containers waardoor een betalende klant mogelijk gegevens kon teruglezen die andere klanten eerder op dezelfde server hadden achtergelaten. Het ging om restdata op schijfruimte, niet om data uit een actief draaiende workload. Daarmee is het risico anders dan bij klassieke uitlek- of RCE-incidenten, maar het blijft een serieus privacyprobleem.
In dit artikel zetten we op een rij wat er precies misging, welke producten geraakt werden en hoe Cloudflare de situatie heeft opgeschoond.
Wat is het Cloudflare Containers lek?
De kern van de melding is dat containers binnen Cloudflare’s dienst draaien op servers die met meerdere accounts worden gedeeld. In zo’n omgeving is het cruciaal dat opslag die aan één container is toegewezen, daadwerkelijk wordt opgeschoond voordat het opnieuw wordt gebruikt.
Volgens Cloudflare en de onderzoekers bestond de fout in de manier waarop gedeelde disks waren ingericht. Daarbij werd schijfruimte opnieuw toegewezen zonder standaard opschoonactie, waardoor een nieuw containerproces mogelijk nog data aantrof die eerder in hetzelfde schijfblok was opgeslagen.
Hoe konden onderzoekers restdata teruglezen?
Cloudflare Containers maakt gebruik van disk thin provisioning: opslag wordt opgedeeld in blokken van 64 kilobyte. Wanneer een container wordt verwijderd, worden de betreffende blokken teruggezet naar een pool die gedeeld wordt over accounts.
Het probleem zat in het feit dat die gedeelde blokken een instelling hadden om het normale wissen over te slaan voordat een blok aan de volgende container wordt aangeboden. Wassen is doorgaans de standaardinstelling, maar in dit geval bleef een blok deels gevuld met eerdere inhoud.
De onderzoekers beschrijven dat ze om de resten te verkrijgen een klein stuk data wegschreven in een eerder ongebruikt deel van een blok (vier kilobyte). Vervolgens lazen ze het volledige schijfblok terug op het raw disk-niveau. Het deel dat ze niet overschreven (ongeveer zestig kilobytes) bleek nog bytes van een vorige container te bevatten.
Wat troffen ze aan op de hergebruikte schijfruimte?
In productie-achtige tests rapporteerden de onderzoekers dat ze in een deel van hun pogingen restmateriaal vonden. Daarbij ging het om servers die Cloudflare zelf koos, en volgens Cloudflare kon een aanvaller niet sturen “van wie” de data afkomstig was.
De teruggevonden blokken bevatten volgens de beschrijvingen onder meer structuren zoals directories, pagina’s uit databases en zelfs structureel complete SQLite-databases. De onderzoekers’ write-up vermeldt verder onder andere directory listings, SQLite-databases, profielen uit de Chromium-browser en bestanden zoals .env-achtige omgevingen en credentialmateriaal.
Belangrijk is dat Cloudflare aangeeft dat dit om teruggevonden restdata ging en niet om een situatie waarin live workloaddata van een ander actief wordt gemanipuleerd. Ook melden de onderzoekers dat hun materiaal aan Cloudflare geen namen, identifiers of credentials van derden bevatte, en dat hun analyse scripts vooral counts en validaties uitvoeren in plaats van volledige bestandsinhoud te tonen.
Welke onderdelen van Cloudflare waren geraakt?
Cloudflare vermeldt dat naast Containers ook Cloudflare Sandboxes betroffen waren. Sandboxes draait op dezelfde infrastructuur als Containers en wordt verkocht als veilige plek om onbetrouwbare code te runnen. Dat kan bijvoorbeeld gaan om code die door AI-agenten wordt aangeleverd.
In de openbaarmaking wordt bovendien genoemd dat de onderzoekers het probleem in verband brachten met een andere escape uit een code-sandbox die eerder in de maand was gepubliceerd in het kader van verschillende sandbox-achtige omgevingen.
Hoe heeft Cloudflare het lek verholpen?
Cloudflare voerde de correctie in twee stappen door, omdat het probleem niet alleen in het “nieuwe” toewijsmoment zat, maar ook gevolgen kon hebben voor al lopende structuren.
- Stap 1: wissen terug aanzetten
Cloudflare schakelde het wissen van nieuwe toegewezen blokken opnieuw in. Daardoor werkte de gerapporteerde proof of concept niet meer volgens de onderzoekers nadat die stap was uitgevoerd. - Stap 2: bestaande schijven en caches opschonen
Omdat het aanpassen van wiping alleen voor nieuw toegewezen blokken niet automatisch alle reeds gemapte locaties opschoonde, heeft Cloudflare daarnaast alle bestaande container disk-varianten uitgezet, en ook caches van voorbereide image layers leeggemaakt. Daarbij werden servers afgetapt en opnieuw gestart tijdens “quiet hours”.
Cloudflare geeft aan dat de opschoning was afgerond op 19 september en dat de kwetsbaarheid vijf dagen later werd bekendgemaakt.
Moeten klanten iets doen?
Volgens Cloudflare hoeven klanten niets te doen. De fix en opschoning zijn door Cloudflare zelf uitgevoerd. Dat neemt niet weg dat organisaties die containers of sandbox-omgevingen gebruiken in het algemeen verstandig doen om incident- en privacyprocedures scherp te houden, zeker bij multi-tenant architecturen.
Is het incident breder misbruikt?
Cloudflare geeft aan dat het actief heeft gezocht naar signalen dat iemand anders de methode had toegepast. Hiervoor werden detectiesignaturen samengesteld op basis van de proof of concept van de onderzoekers en een eigen variant van de aanval. Vervolgens werden die signatures gedraaid tegen disk-activiteitsrecords die Cloudflare had bijgehouden.
Het bedrijf meldt dat het alleen activiteit zag van de onderzoekers en van geautoriseerde engineers. Daarmee is er volgens Cloudflare geen bewijs dat de specifieke methode door anderen is gebruikt.
Tegelijk blijft één detail onduidelijk: Cloudflare staat niet stil bij tijdspanne of wanneer precies de onveilige instelling is ontstaan. Daardoor is de exacte duur van de blootstelling niet volledig te herleiden uit de beschrijving.
Waarom dit ook relevant is voor AI-agenten en sandboxing
Sandboxing wordt vaak gezien als veiligheidslaag voor het uitvoeren van onbetrouwbare code. In de praktijk schuilt een deel van het echte risico in details rondom isolatie: niet alleen of code kan escaleren naar de host, maar ook of dataresiduen of opslaghergebruik kunnen lekken.
Als je AI-agenten inzet die code genereren en uitvoeren in omgevingen die niet volledig geïsoleerd zijn (bijvoorbeeld multi-tenant containers of sandbox-varianten), dan is dit soort incidenten een reminder dat “veilig uitvoeren” méér omvat dan alleen executiecontrole.
Voor bredere achtergrond over hoe aanvallen via agents en runtimebeveiliging kunnen samenlopen, kun je ook lezen: AI-agent runtime security: wat Kontext belooft.
Praktische aandachtspunten voor organisaties
Ook al zegt Cloudflare dat klanten niets hoeven te doen, kunnen organisaties uit dit type incident wél lessen trekken. Denk aan de volgende punten:
- Valideer data-opschoning: check of de leverancier expliciet beleid voert rond wissen en hergebruik van opslagblokken.
- Let op multi-tenant grenzen: hoe meer accounts op dezelfde hardware, hoe belangrijker het is dat isolatie ook opslag-niveau dekt.
- Onderhoud logging en detectie: als er restdata kan worden uitgelezen, dan zijn auditsporen en detectiesignaturen essentieel.
- Beperk gevoelige data: ook binnen containers is het verstandig om credentials of persoonlijke gegevens niet onnodig op schijf te laten staan.
Als je geïnteresseerd bent in hoe beveiliging soms omzeild kan worden in omgevingen die bedoeld zijn voor “veilige” uitvoering, is dit vergelijkbare perspectief mogelijk ook relevant: AI doomsday-scenario’s: risico’s en realiteit.
Conclusie
Het Cloudflare Containers lek draaide om een opschoningsfout bij thin-provisioned opslagblokken. Daardoor konden onderzoekers restdata lezen die andere containers eerder hadden achtergelaten op dezelfde server. Cloudflare heeft het probleem stap voor stap opgelost door wiping terug aan te zetten en vervolgens ook bestaande containerdisks en caches te verwijderen.
Voor gebruikers geldt: Cloudflare stelt dat er geen actie nodig is. Tegelijk biedt het incident waardevolle inzichten voor iedereen die sandboxing of containergebaseerde multi-tenant uitvoering inzet, ook in AI-contexten.
Bron: https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html
