Cloudflare has fixed a vulnerability in Cloudflare Containers that could have let one customer read leftover data from another customer’s container storage. The company says it has no evidence that customer data was compromised, and customers do not need to take any action.
Security researcher Oren Yomtov of Accomplish reported the issue on September 4, 2026, through Cloudflare’s bug bounty program, Cloudflare said in a detailed post. The flaw also affected Cloudflare Sandboxes, which is built on Containers.
How Leftover Disk Blocks Leaked Data
Cloudflare Containers give each container a writable root disk through Linux device mapper thin provisioning, known as dm-thin. Each container runs inside its own virtual machine powered by Firecracker.
Thin provisioning assigns physical storage only when a disk writes to an unused region. The affected pools used 64 KiB blocks and an option called skip_block_zeroing. With that option set, reused blocks were not cleared before a new container got them.
A small write replaced only part of a reused block. The researchers wrote one 4 KiB block into each 64 KiB region. The remaining 60 KiB could still hold data from a previous container, and a raw read of the disk could return it.
What the Researchers Found
A customer with a Workers Paid account could run the technique. It could not target a particular customer, workload or host, and leftover data was not guaranteed to be present.
Across six production placements, the researchers tested 5,614 directory blocks and attributed none of them to their own test filesystem. They observed residual material on 18 of 24 placements and 20 of 22 underlying nodes across four continents.
The recovered block types included directory structures, database pages and complete SQLite databases. The researchers reported only aggregate counts, and they confirmed they securely deleted the recovered data.
How Cloudflare Closed the Gap
Cloudflare first removed skip_block_zeroing from the pool configuration across its fleet. That restored dm-thin’s default of clearing new blocks before a container can see them. The researchers confirmed their proof of concept no longer worked.
Zeroing new blocks did not clean blocks already mapped into existing disks or cached image layers. Cloudflare therefore retired all running container disks and removed cached image snapshots created before the fix. It drained hosts during off-peak hours and restarted the virtual machines on each host.
The company also built detection signatures from the exploit’s pattern of small writes followed by large reads. Reviewing its retained disk telemetry, it found only activity from the researchers and its own engineers.
What the Timeline Shows
Cloudflare opened a security incident about three hours after the report and merged a runtime fix the same evening. It finished rolling out the changes on September 7. The researchers reported on September 14 that their proof of concept had stopped working, and Cloudflare awarded a bounty that day.
For teams running workloads on shared cloud infrastructure, the case is a reminder that storage settings can matter as much as network isolation. A single configuration option decided whether reused disk blocks were wiped.
