Cloudflare fixes cross-tenant data exposure in Containers

On September 4, 2026, Oren Yomtov, a security researcher at Accomplish, reported a vulnerability in Cloudflare Containers and the Sandboxes built on top of them through Cloudflare's bug bounty program. Cloudflare says it has fully remediated the issue and found no evidence that customer data was compromised.

What the flaw was

Containers run on multi-tenant infrastructure and are placed on servers automatically — customers cannot choose the host. The researchers demonstrated that a Workers Paid account holder could recover residual disk blocks previously belonging to other tenants' containers on the same server. The technique could not target a specific customer, workload, or data, and residual content was not guaranteed to be present.

Each container gets a writable root disk via Linux device mapper thin provisioning (dm-thin), running inside a dedicated Firecracker virtual machine where the disk appears as /dev/vdc. Physical storage is allocated only on the first write to an unmapped region. The culprit was the skip_block_zeroing option: with it enabled, dm-thin did not zero newly allocated 64 KiB blocks. If a new container wrote only 4 KiB into such a block, the remaining 60 KiB kept the previous owner's contents, readable directly from the raw device.

What could be recovered

To tell their own blocks apart from foreign ones, the researchers used ext4 directory-block checksums. Across six production placements, none of 5,614 testable blocks belonged to their own filesystem, while 2,700 foreign directory inodes surfaced. In total, residual data appeared on 18 of 24 placements and 20 of 22 nodes across four continents, including directory structures, database pages, and complete SQLite databases. According to Cloudflare, the submitted materials held no filenames, credentials, or recovered values, and the researchers confirmed they had securely deleted the recovered data.

The fix

Cloudflare first removed skip_block_zeroing from pool configurations fleet-wide, restoring dm-thin's default of clearing new blocks; the proof of concept then stopped working, as the researchers confirmed. But zeroing did not sanitize blocks already mapped into running disks or into cached snapshots of prepared image layers. So Cloudflare, during off-peak hours, retired all running container disks, restarted the VMs, and cleared each host's image cache so disks were rebuilt with zeroed allocations.

A review of historical disk-I/O telemetry turned up activity only from the researchers and Cloudflare engineers running authorized validation; no third-party exploitation was found. From the initial report on September 4 to completing cleanup across the whole fleet on September 19, the response took a little over two weeks.

Source: Cloudflare Blog