Cloudflare has disclosed and fixed a cross-tenant data exposure vulnerability in Cloudflare Containers and Cloudflare Sandboxes, which are built on Containers. The flaw let a paying customer recover leftover disk data from other customers' workloads that had previously run on the same physical host. It was found and responsibly disclosed by Oren Yomtov, a security researcher at Accomplish, through Cloudflare's HackerOne program on 4 September 2026. Cloudflare fixed it in production the same day, spent two weeks scrubbing residual state, and says its telemetry shows no sign anyone else ever exploited it.
To be clear about provenance: IKZERO did not discover this vulnerability and played no part in the disclosure. This post is our technical read of Cloudflare's own disclosure (written with the researchers and authored by Avishek Sarkar) — because the mechanics are a masterclass in how multi-tenant storage leaks data, and the remediation teaches a lesson most infrastructure teams learn only after an incident.
What happened
| Field | Value |
|---|---|
| Product | Cloudflare Containers and Cloudflare Sandboxes |
| Class | Cross-tenant residual data disclosure through shared-block storage |
| Discovered by | Oren Yomtov (Accomplish), reported via HackerOne, 4 September 2026 |
| Root cause | dm-thin pools configured with skip_block_zeroing on 64 KiB thin blocks |
| Reach | Residual material found on 18 of 24 placements, 20 of 22 hosts, across four continents |
| Fixed | Fleet-wide by 7 September; cached snapshot cleanup completed 19 September |
| Exploitation | None identified in Cloudflare's historical disk-I/O telemetry |
| Customer action required | None. No configuration changes on the customer side |
Cloudflare Containers give each workload a Firecracker microVM with a writable root disk presented as /dev/vdc. Under the hood that disk is a Linux device-mapper thin volume (dm-thin): physical storage is allocated only when the guest writes to a region it has never touched. The affected storage pools used 64 KiB thin blocks, and — this is the loaded gun — were configured with the skip_block_zeroing option, which tells dm-thin not to clear a freshly allocated block before handing it over.
When a container's thin volume is deleted, its physical blocks return to a pool that serves workloads from multiple customer accounts. With zeroing disabled, the next tenant that triggers allocation of one of those blocks inherits whatever the previous owner last wrote there.
The technique: write small, read big
The first thing to understand is what does not leak. Reading an unmapped region of a thin disk returns zeroes — dm-thin answers from a zero page without ever allocating physical storage. A new tenant cannot just dd its way to another customer's data.
The proof of concept instead exploited the gap between the thin block size and the guest's write size:
- Create a container on a Workers Paid account and open the raw root disk,
/dev/vdc. - Find 64 KiB-aligned regions corresponding to free space in the guest's ext4 filesystem.
- Write one 4 KiB block into each region.
- When a 4 KiB write lands on an unmapped thin block, dm-thin allocates a physical 64 KiB block from the shared pool — and with
skip_block_zeroingenabled, the write replaces only the first 4 KiB. - Read the full 64 KiB back. The untouched 60 KiB can hold bytes the previous tenant wrote and believed were gone.
One unprivileged write-and-read cycle per block, from a standard paid account, with no way to aim it: the attacker cannot choose the victim, the host, or the data. Exposure was a lottery drawn by Cloudflare's placement scheduler — but with enough draws, the lottery pays out.
Proving the blocks belong to strangers
Rescued bytes are only evidence if you can show they are not your own, and this is the most elegant part of the research. Modern ext4 with the metadata_csum feature stamps every directory block with a checksum derived from filesystem- and inode-specific values. A block recovered from another tenant's filesystem checksums against their filesystem, not yours.
Running this attribution across six production placements, the researchers reported:
- 5,614 testable directory blocks recovered;
- 0 of them belonging to the researchers' own filesystem;
- 2,700 distinct foreign directory inodes identified.
The method was validated against 162 blocks the researchers had deliberately created and deleted in their own test filesystem — all 162 attributed correctly. In total, residual material appeared on 18 of 24 placements and 20 of 22 underlying hosts across four continents, including directory structures, database pages, and structurally complete SQLite databases. Notably, the researchers' tooling emitted only aggregate counts and format checks — no third-party file contents ever entered the report — and they confirmed secure deletion of everything recovered. That is textbook responsible disclosure, and it deserves to be said as plainly as the vulnerability does.
What made it serious — and what contained it
The exposure crossed the tenant-isolation boundary: filesystem metadata, directory structures, database pages, application data. That is as bad as residual-data bugs get. Three factors contained it:
- No targeting. Placement was Cloudflare-controlled; an attacker could not pursue a specific victim, workload, or dataset.
- No live disks. Actively attached volumes were never readable through this path — only blocks already released to the shared pool.
- Read-only. The researchers demonstrated disclosure, not modification of another customer's data or any impact on availability.
The fix was two moves, not one
Cloudflare's first change — removing skip_block_zeroing from every dm-thin pool — restores the default behaviour of clearing newly allocated blocks. The researchers independently confirmed the proof of concept stopped working. Done, right?
Not quite, and this is the part worth underlining for anyone who runs storage infrastructure: fixing the configuration does not sanitise the blocks already mapped. Two categories of pre-fix residue survived the config change:
- Blocks already mapped into running container disks.
- Blocks mapped into each host's cache of prepared dm-thin snapshots for OCI image layers — a new container can inherit mappings from a cached layer without allocating anything, keeping residual bytes in that layer's unused regions readable.
So Cloudflare drained hosts during off-peak hours, restarted every VM, retired all running container disks, and cleared each host's image cache, forcing everything to be recreated with zeroed allocations. Cleanup across the fleet completed on 19 September — fifteen days after the report.
The general lesson: remediating a residual-data bug means enumerating every place old bytes can still be mapped — running volumes, caches, snapshots, backups — not just closing the allocation path.
Speed as a control
The timeline is its own lesson. Report received 4 September 15:26 UTC; production misconfiguration confirmed 18:45; runtime fix merged 21:27; rollout started 23:15 — all inside eight hours. Rollout completed 7 September; the researchers independently confirmed the PoC stopped working on 14 September; the bounty was awarded the same day.
Cloudflare also went further than patching: it built detection signatures from the PoC's write/read signature (small write, then reads recovering far more than was written) and ran them against historical disk-I/O telemetry, finding activity only from the researchers and Cloudflare's own authorized validation. "We have no evidence of exploitation" is a claim most victims cannot make — because they lack the telemetry to make it.
What this means for your stack
- Building on Cloudflare Containers or Sandboxes? You take no action. The fix is entirely on Cloudflare's side, completed fleet-wide, with no evidence your data was exposed to anyone.
- Running your own multi-tenant storage — container platforms, CI runners, sandboxing products, VPS hosting — treat this as a checklist item, not a curiosity. Verify that block zeroing on allocation is enabled everywhere, that "delete" actually means "sanitise", and that image/layer caches get the same scrutiny as live volumes.
- If you sell isolation as a feature, telemetry that can disprove exploitation is part of the product. Cloudflare could state "no one else did this" because it could see disk I/O historically. If you cannot make that statement after an incident, close that gap before the incident.
- And when your team finds something like this — the Accomplish playbook is the one to copy: controlled testing, aggregate metrics only, no third-party data retained, coordinated disclosure through the vendor's program.
Cloudflare's disclosure credits Oren Yomtov and the Accomplish team for the research and collaboration, and we add our own thanks here — this is exactly the kind of work that makes multi-tenant platforms safer for everyone operating on them.
Frequently Asked Questions
Was my Cloudflare workload or data affected?
Cloudflare has no evidence that any customer data was compromised, and its telemetry shows no exploitation beyond the researchers' authorized testing. The flaw could not target specific victims, and it exposed only residual blocks from already-deleted volumes, never active disks. No customer-side changes are required.
What is skip_block_zeroing in dm-thin?
It is a device-mapper thin-provisioning option that skips clearing newly allocated physical blocks before they are handed to a volume, trading safety for allocation speed. With it enabled, a fresh allocation keeps the previous owner's bytes until something overwrites them. Cloudflare's affected pools used it on 64 KiB thin blocks; removing it restored zeroing on allocation fleet-wide.
Who discovered the Cloudflare Containers vulnerability?
Oren Yomtov, a security researcher at Accomplish, who reported it through Cloudflare's HackerOne bug bounty program on 4 September 2026. Cloudflare's disclosure was co-authored with the researchers, who recovered only aggregate statistics, kept recovered data confidential, and securely deleted it after validation.
I run my own container hosts. Should I check anything?
Yes. If your workloads share physical storage across tenants or trust boundaries, verify that thin-provisioning pools zero new allocations (no skip_block_zeroing equivalent), that volume deletion triggers actual sanitisation, and that image-layer caches and snapshots are included in that review. Deletion is not sanitisation, and a cache is a mapping, not a copy.
Cross-tenant isolation is a promise you make to every customer the moment two workloads share a machine, and it is broken by config flags as often as by exotic memory bugs. This is the class of flaw we hunt for in a penetration test, the operational discipline we install through DevSecOps pipeline integration, and the design review we run for teams building multi-tenant products via security consultancy. If you cannot confidently answer where your deleted bytes go, talk to us and we will find out with you.
