Cloudflare Containers leaked leftover disk blocks between customers, and researchers recovered 60 KiB from each reused region

Every serverless platform sells one promise before all the others: your data cannot be read by anyone else running on the same machine. On 4 September a security researcher gave Cloudflare a proof that its Containers platform had been quietly breaking that promise, and on 24 September Cloudflare published the full account of what went wrong.

Cloudflare says Oren Yomtov of the security research team at Accomplish reported the flaw through HackerOne. It affected Cloudflare Containers and Cloudflare Sandboxes, which is built on Containers. Cloudflare says it has fully fixed the vulnerability, no customer action is required, and its historical disk telemetry shows no sign that anyone other than the researchers and its own engineers used the technique.

The setting that let one customer read another's leftover data

Each container runs inside a Firecracker virtual machine with a writable root disk backed by Linux device mapper thin provisioning. Cloudflare says the pool serving that disk was configured with skip_block_zeroing, which tells the kernel not to clear a new 64 KiB block before handing it to a container. A full 64 KiB write replaced the block. A smaller write only replaced the part it touched, and the remaining bytes could still hold whatever the previous owner had written there.

The proof of concept scanned the fresh disk for 64 KiB regions inside the ext4 filesystem's free space, wrote a single 4 KiB block into each one, then read the raw device. Cloudflare says the researchers used ext4 directory-block checksums to tell their own blocks apart from foreign ones. Across six production placements, all 5,614 testable directory blocks belonged to other filesystems, and the checksum analysis identified 2,700 distinct foreign directory inodes. On a wider sweep, residual material appeared on 18 of 24 placements across 20 of 22 underlying nodes on four continents. The recovered block types included directory structures, database pages and complete SQLite files.

What the fix actually did

Cloudflare says its first mitigation was to remove skip_block_zeroing from the pool configuration across the fleet, which restored the kernel's default of clearing new blocks before exposing them. The researchers reported that their proof of concept stopped working after that change.

Zeroing new allocations did not clean up blocks that were already mapped into running containers or into each host's cache of prepared image snapshots. A new container could inherit those older mappings and still read residual bytes through the raw device. Cloudflare says it drained hosts during off-peak hours, restarted the virtual machines, and cleared each host's image cache so that new disks and layers were built from zeroed allocations. Its published timeline shows the mitigations rolling out from 4 September at 21:27 UTC, with the pre-mitigation snapshot cleanup completing on 19 September at 15:03 UTC.

An attacker with a Workers Paid account could not pick a target: block reuse depended on Cloudflare's own placement decisions and which released blocks the pool reassigned. The researchers also did not demonstrate modification of another customer's live data.

The write-up lets a team weigh serverless container platforms against its own compliance work. It states the exact kernel option, quantifies how often residual material appeared, and names the second cleanup step the fix required. A serverless container is quick to reach for and hard to check from the outside, so the trust rests on posts like this being accurate and quick.

Source

• Cloudflare, How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers, by Rushil Mehra, Cody Roseborough, Avishek Sarkar and Hrushikesh Deshpande, 24 September 2026.