Cloudflare recently revealed a cross-tenant data exposure vulnerability in its Containers platform, which also powers Cloudflare Sandboxes. Customers on Workers Paid accounts could retrieve leftover disk blocks abandoned by other customers' containers running on the same host machine. The company has fixed the issue and reports finding no signs that anyone exploited it maliciously. The breakdown occurred not at the virtual machine security boundary but in the storage allocation system sitting beneath it.
Security researcher Oren Yomtov from Accomplish flagged the problem on September 4 through Cloudflare's bug bounty program. The researchers tested the vulnerability across six production placements and discovered that all 5,614 testable directory blocks originated from other customers' workloads, identifying 2,700 distinct foreign directory inodes. Leftover material showed up on 18 of 24 placements and 20 of 22 underlying nodes spread across four continents. The recovered block types included directory structures, database pages, and structurally intact SQLite databases. The researchers used ext4 directory block checksums to distinguish their own blocks from those belonging to everyone else.
According to the report, Cloudflare is precise about the limitations an attacker would face: they couldn't pick a victim, select a specific workload or host, read a disk that's actively attached, or count on residual data being there at all. Exposure hinged on where Cloudflare assigned the workload and which released blocks the system happened to reassign. The researchers didn't show they could modify another customer's data or disrupt service availability. Peter Ward, a senior cloud security engineer at Visa, called the pattern a familiar one, describing it as tenant isolation failing at the storage layer rather than an application flaw. Sherin Shahanas, a technology leader in cloud and cybersecurity, noted that the root cause is seldom confirmed independently, pointing out that "isolated" typically remains an architectural assertion rather than something tested at the storage layer.
The technical cause traced back to configuration choices made for performance. Each Cloudflare container operates inside a Firecracker virtual machine with a writable root disk, set up through Linux device mapper thin provisioning. The affected storage pools used a 64 KiB thin-block size and were configured with skip_block_zeroing, which instructs the system not to wipe newly allocated blocks before exposing them. Writing a single 4 KiB block into an unmapped region triggered the system to allocate a 64 KiB physical block from a pool shared across customer accounts, but the write only replaced its own portion—leaving up to 60 KiB that could still contain whatever the previous container had written there. A raw disk read could then return bytes the new container never wrote. The disclosure arrived within days of Microsoft making Azure Container Apps Sandboxes generally available and Google publishing benchmarks for GKE Pod snapshots, both pitching isolation for agent workloads that run untrusted code—a reminder that the guarantee must extend through every layer beneath the one advertised, including the block allocator.
Cloudflare's response timeline shows both speed and the limits of a simple fix. The report arrived at 15:26 UTC on September 4, and Cloudflare opened an incident at 18:45, merged a runtime fix at 21:27, merged changes for new and live pools at 22:03, and began deploying at 23:15 the same day. The rollout finished on September 7. But removing skip_block_zeroing only restored default behavior for newly allocated blocks—it didn't sanitize blocks already mapped into existing thin devices, whether in running container disks or in each host's cache of prepared snapshots for container image layers. A fresh container could inherit those mappings without allocating the blocks again. Cloudflare therefore retired all running container disks, drained hosts during off-peak hours, restarted the virtual machines, and cleared each host's image cache—cleanup that wrapped up on September 19. Upon detection, Cloudflare built signatures from the telltale pattern of a small write followed by a larger read, applied them to retained historical disk-I/O telemetry, and found only activity tied to the researchers and to its own engineers running authorized validation. The researchers confirmed their proof of concept stopped working after the change, and that recovered data under their control was securely erased following submission. Cloudflare awarded the bounty on September 14. If these reactions are representative, the lesson practitioners are drawing centers on verification rather than vendor selection—the question isn't which platform to trust, but whether deallocated blocks are zeroed before reuse, a control that should be tested rather than assumed. Organizations running multitenant infrastructure may find that a storage-layer misconfiguration can unravel isolation guarantees built into every layer above, turning architectural confidence into a blind spot that only independent testing will catch.