On September 4, 2026, security researcher Oren Yomtov from Accomplish reported a cross-tenant data exposure vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes via the company’s bug bounty program. Users with a Workers Paid account were able to retrieve remnant disk blocks from other customers’ containers residing on the same physical host.
How Storage Allocation Caused the Isolation Gap
Cloudflare Containers run inside Firecracker virtual machines equipped with a writable root disk provisioned through Linux device mapper thin provisioning (dm-thin), infoq.com reported. The affected storage pools utilized a 64 KiB thin-block size and were configured with the skip_block_zeroing option, which instructs dm-thin to omit clearing newly allocated blocks before making them accessible.
This configuration allowed a single 4 KiB write into an unmapped region to trigger the allocation of a 64 KiB physical block from a pool shared across multiple customer accounts. The write replaced solely its own 4 KiB portion, leaving up to 60 KiB of residual data from a previous container intact on the disk.
Testing Results Across Global Infrastructure
Researchers utilized ext4 directory block checksums to isolate their test blocks from foreign data. Across six production placements, all 5,614 testable directory blocks originated elsewhere, identifying 2,700 distinct foreign directory inodes, infoq.com reported. Residual material surfaced on 18 of 24 placements and across 20 of 22 underlying nodes spanning four continents, returning complete structures like SQLite databases.
Despite the recovery of raw blocks, Cloudflare stated that the technique could not target a specific customer, workload, host, or active disk, and did not guarantee that residual data would be present.
Remediation Timeline and Fleet Cleanup
Removing the skip_block_zeroing setting restored default behavior for newly allocated blocks, but it left existing thin devices and cached image snapshots unchanged.
To remove persistent mappings, Cloudflare cleared the image cache of every host, restarted virtual machines, drained hosts during low-traffic periods, and retired all active container disks, finishing all mitigation steps by September 19, 2026. Reviewing historical disk-I/O telemetry with custom signatures revealed no evidence of malicious exploitation prior to the fix, with all detected activity traced solely to the researchers and Cloudflare engineers.
Security Community Reactions to Shared Infrastructure
Security practitioners on LinkedIn focused discussions on isolation boundaries at the storage layer rather than application bugs. Peter Ward, a senior cloud security engineer at Visa, argued that shared hosts and ephemeral disks require explicit zero-on-allocate or wipe-on-release checks in the control plane rather than relying solely on network isolation.
Frequently Asked Questions About the Cloudflare Container Vulnerability
Which accounts and services were affected by the vulnerability?
Customers using Cloudflare Containers and Cloudflare Sandboxes on a Workers Paid account were affected, as these services run on multi-tenant infrastructure where workloads are automatically assigned to eligible servers.
How was the security flaw initially discovered and reported?
Oren Yomtov, a security researcher at Accomplish, discovered the issue and reported it through Cloudflare’s bug bounty program on September 4, 2026.
What specific configuration setting caused the data exposure?
The vulnerability stemmed from shared storage pools configured with skip_block_zeroing, a dm-thin option that skips clearing newly allocated blocks before exposing them to workloads.
Did Cloudflare find any evidence of active exploitation in the wild?
No. After applying detection signatures to historical disk-I/O telemetry, Cloudflare found no evidence of malicious exploitation, confirming that all observed activity matching the technique came from the researchers and internal engineers.
Keep reading