skip_block_zeroing let a 4 KiB write return 60 KiB of another tenant's disk

On September 4, 2026, Oren Yomtov, a security researcher from Accomplish, reported a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes (which is built on Containers) through Cloudflare's bug bounty program.

Cloudflare says it has fully remediated the vulnerability and has no evidence that customer data has been compromised.

The researchers demonstrated that a customer with a Workers Paid account could recover residual disk blocks previously used by Containers on the same host.

Within the historical disk-I/O telemetry available to it, Cloudflare identified no evidence of malicious exploitation; activity it could attribute to the reported technique came from the researchers and Cloudflare engineers conducting authorized validation.

Cloudflare Containers use Linux device mapper thin provisioning (dm-thin) to provide each container with a writable root disk.

Each container lives inside a dedicated virtual machine powered by the Firecracker virtual machine monitor, and Firecracker presents the disk to the virtual machine as /dev/vdc.

Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region, and the affected storage pools used a 64 KiB thin-block size.

When the thin volume backing a container's root disk was deleted, its physical blocks were returned to a pool that served workloads belonging to multiple customer accounts.

The affected pool configuration included the option skip_block_zeroing; with it configured, dm-thin skips zeroing newly allocated blocks before making them accessible.

With block zeroing disabled, a full-block write replaced a reassigned block's previous contents, but a smaller write changed only the written portion, and the remainder could retain data from the block's previous owner.

Reading an unmapped region of a new thin disk did not reveal residual data: for an unmapped region of the thin device, dm-thin returned zeroes without allocating a physical block.

When such a write reached an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool; the 4 KiB write replaced only that portion, the remaining 60 KiB could retain data from a previous container, and a subsequent raw-device read could observe bytes the new container had never written.

The researchers used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem, created for the proof of concept, from blocks originating from other filesystems; when ext4 uses the metadata_csum feature, directory block checksums incorporate values associated with the filesystem and inode.

The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes, and the materials provided to Cloudflare contained no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values; the researchers confirmed that they securely deleted the recovered data.

Cloudflare's post was prepared in collaboration with Oren Yomtov and the Accomplish security research team, whose detailed report and controlled testing helped Cloudflare validate the issue and respond.

The proof of concept identified 64 KiB-aligned regions corresponding to free space in the guest's ext4 filesystem and wrote one aligned 4 KiB block into each region.

The proof of concept created a container using a Workers Paid account, opened the writable root disk at /dev/vdc, recorded a baseline read, wrote one 4 KiB block into each selected 64 KiB region corresponding to ext4 free space, read the blocks again, and examined only the portions not overwritten by the new container.

The 4 KiB write covered one sixteenth of the allocated 64 KiB block, leaving 93.75 percent of the block available to a read of data the new container never wrote.