Cloudflare heeft een kwetsbaarheid in haar Containers-platform weten te verhelpen, die mogelijk het isolatieprincipe tussen klanten had ondermijnd door gebruik te maken van fysieke opslagblokken. Een onderzoeksleider slaagde erin residuale gegevens terug te vinden die van andere containers in dezelfde omgeving afkomstig waren, doordat de dm-thin-configuratie niet alle blokken volledig had gewist voordat ze opnieuw werden toegewezen.
De essentie van de Cloudflare Containers-kwetsbaarheid in 20 seconden
- De fout lag in de opslaglaag en betrof fysieke blokken van 64 KiB.
- Een write van slechts 4 KiB kon de resterende 60 KiB blootstellen.
- Tests brachten directorystructuren en data gerelateerd aan databases aan het licht.
- De onderzoeker vond residu-gegevens op 18 van de 24 onderzochte locaties.
- Cloudflare verwijderde de kwetsbare configuratie, oude snapshots en vond geen bewijs van kwaadaardig gebruik.
Het incident werd op 4 september 2026 gemeld aan Cloudflare door Oren Yomtov, onderzoeker bij Accomplish, via het beveiligingsbonusprogramma van het bedrijf. Cloudflare stelt dat de kwetsbaarheid is opgelost en dat verder onderzoek geen aanwijzingen heeft gevonden dat derden de kwetsbaarheid voor kwaadaardige doeleinden hebben aangegrepen.
De fout betrof Cloudflare Containers en indirect ook Cloudflare Sandboxes, dat op dezelfde technologie gebaseerd is. Het bijzonder kritieke punt was het multi-tenant karakter van de infrastructuur: verschillende klanten konden fysiek opslagmateriaal delen uit dezelfde pool.
Het onderzoek toont aan dat het logische isolatieprincipe tussen containers niet voldoende was om restantgegevens van vorige eigenaren te voorkomen onder bepaalde omstandigheden.
Een write van 4 KiB kon 60 KiB aan gegevens blootstellen
Cloudflare gebruikt dm-thin, het lichte provisioning-systeem van Linux, voor het leveren van schrijfbare root-disks aan containers. Elke container draait binnen een Firecracker-virtual machine en krijgt opslag via het apparaat /dev/vdc.
Het systeem reserveert niet vooraf al het fysieke opslagmateriaal. In plaats daarvan worden blokken toegewezen zodra een bepaald deel van de virtuele schijf wordt beschreven.
De getroffen pools gebruikten fysieke blokken van 64 KiB. Bij het verwijderen van een container konden deze blokken terugkeren naar de gedeelde pool en later worden opnieuw toegewezen aan andere workloads.
De problematische configuratie omvatte de optie skip_block_zeroing. Deze instelling zorgde ervoor dat dm-thin een fysiek blok niet wist voordat het werd toegewezen aan een nieuw volume.
Het gevolg hiervan was dat, wanneer een container slechts 4 KiB schreef, de overige 60 KiB buiten dat schrijfproces niet werden gewist en dus informatie konden bevatten van eerdere gebruikers.
De onderzoeker ontwikkelde een proof-of-concept waarmee hij vrije ruimte in het ext4-bestandssysteem kon detecteren, 4 KiB writes kon uitvoeren op uitgelijnde blokken en vervolgens kon controleren welke gegevens in onbehandelde zones zichtbaar bleven.
Het direct lezen van het apparaat maakte het mogelijk om data te zien die door de nieuwe container nooit waren gegenereerd.
De onderzoeker kon blokken van andere systemen identificeren
De studie beperkte zich niet tot residuele bytes. Om data te onderscheiden van eigen informatie en data van andere systemen, gebruikte het team checksums van directoryblokken in ext4.
Volgens Cloudflare onderzochten de onderzoekers 5.614 directoryblokken op zes productie-omgevingen. Geen van deze werd gelinkt aan het bestandssysteem dat voor de test was gebruikt.
Het analyseproces leidde ook tot de identificatie van 2.700 directory-inodes, die met ext4-checksums waren gekoppeld aan andere bestandssystemen.
Residu-gegevens werden gevonden in 18 van de 24 locaties en op 20 van de 22 onderliggende nodes verspreid over vier continenten. Tijdens de validatie werden onder meer directorystructuren, databasepagina’s en volledige SQLite-databases aangetroffen.
De reikwijdte van deze bevinding was echter duidelijk begrensd. Het was niet mogelijk om een specifieke klant te targeten of directe toegang tot een actief exemplaar van een ander systeem te krijgen. De blootstelling hing af van de mogelijkheid dat het systeem bepaalde blokken opnieuw toewijst die nog restgegevens bevatten.
Ook kon niet worden bewezen dat het mogelijk was om actieve gegevens van een andere klant te wijzigen of de beschikbaarheid van diens workloads te beïnvloeden.
Cloudflare moest meer doen dan alleen config aanpassen
De eerste maatregel van Cloudflare was het verwijderen van skip_block_zeroing uit de dm-thin-pools, zodat nieuwe toewijzingen nu weer de blokken volledig zouden wissen voordat ze aan een container worden toegewezen.
Echter, de organisatie ontdekte dat het aanpassen van nieuwe toewijzingen onvoldoende was om residu-gegevens op bestaande disks en in caches te verwijderen.
Sommige blokken bleven mogelijk gemapt binnen draaiende containers, en hosts hielden snapshots in cache die vooraf waren gemaakt voor OCI-image layers. Een nieuwe container kon dergelijke mappings erven zonder dat er fysiek een nieuw blok werd toegewezen.
Daarom besloot Cloudflare om de aangetaste disks en de vooraf gemaakte snapshots te verwijderen en te vervangen door nieuwe resources met correct geïnitialiseerde blokken.
Dit proces omvatte het ontladen van hosts, het herstarten van virtuele machines en het legen van caches. Vervolgens werden de resources opnieuw opgebouwd met juiste toegewezen en gewiste blokken.
De organisatie bevestigt dat alle snapshots vóór de mitigatie volledig werden verwijderd op 19 september 2026.
Geen bewijs van kwaadaardig gebruik gevonden
Cloudflare heeft ook de historische disktelemetrie geanalyseerd om te controleren of iemand aan de hand van soortgelijke technieken eerder misbruik heeft gemaakt.
Het team ontwikkelde detectiesignaturen gebaseerd op het gedrag dat tijdens de test was waargenomen, zoals schrijfpatronen van 4 KiB die konden leiden tot hergebruikte 64 KiB-blokken, en het uitlezen van gegevens die buiten de overschrijfzone lagen.
Deze analyse identificeerde activiteiten van onderzoekers en Cloudflare-engineers tijdens de toegestane tests. Volgens Cloudflare zijn er geen aanwijzingen gevonden dat de techniek in andere contexten werd toegepast.
Het bedrijf stelt daarom dat er geen bewijs is van kwaadaardig misbruik van deze kwetsbaarheid.
Deze situatie onderstreept het belang van meerdere beveiligingslagen in multi-tenant cloud-omgevingen. Zelfs als containers effectief zijn gescheiden, kan een verkeerde configuratie in het opslagbeheer, caches of snapshots leiden tot gegevensresidu die mogelijk kan worden uitgelezen.
De aanpak van Cloudflare toont ook dat het aanpassen van configuraties mogelijk aanvullende maatregelen vereist, vooral wanneer er gebruik wordt gemaakt van persistent resources of vooraf opgeslagen snapshots. In dit geval rekende het bedrijf niet enkel op het wijzigen van dm-thin, maar verving ook oude disk resources en maakte nieuwe snapshots aan.
Volgens Cloudflare konden klanten de fix toepassen zonder wijzigingen in hun eigen configuraties. Het bedrijf waardeerde de responsible disclosure van de onderzoeker en het team van Accomplish voor deze aanpak.
Veelgestelde vragen
Wat liet de Cloudflare Containers-kwetsbaarheid toe?
Het kon een klant mogelijk maken om residuale gegevens van opslagblokken te herstellen die eerder door andere containers in dezelfde fysieke omgeving werden gebruikt.
Waarom was een schrijfbeurt van 4 KiB voldoende?
Omdat de fysieke blokken 64 KiB groot waren en de configuratie niet alle gegevens wist voor het opnieuw toewijzen, kon een write van slechts 4 KiB achterblijvende gegevens achterlaten van 60 KiB.
Welke gegevens vonden de onderzoekers?
Tijdens de tests werden directorystructuren, databasepagina’s en volledige SQLite-databases gevonden, naast andere residu-gegevens van bestandssystemen.
Heeft Cloudflare een aanval bevestigd?
Nee. Cloudflare verzekert dat haar analyse van de beschikbare telemetrie geen activiteiten heeft aangetoond die wijzen op misbruik, buiten de door onderzoekers en engineers uitgevoerde toegestane tests.