Cloudflare recently disclosed a cross-tenant data exposure vulnerability in Containers, the platform that also underpins Cloudflare Sandboxes. A customer on a Workers Paid account could recover residual disk blocks left behind by other customers' containers on the same host. Cloudflare has remediated it and says it found no evidence of malicious exploitation. The failure was not in the virtual machine boundary but in the storage allocator beneath it.
Oren Yomtov, a security researcher at Accomplish, reported the issue on September 4 through Cloudflare's bug bounty program.
Each Cloudflare container runs inside a Firecracker virtual machine with a writable root disk, provisioned through Linux device mapper thin provisioning. The affected pools used a 64 KiB thin-block size and were configured with skip_block_zeroing, which tells dm-thin not to clear newly allocated blocks before exposing them.
That combination created the gap. Writing a single 4 KiB block into an unmapped region caused dm-thin to allocate a 64 KiB physical block from a pool shared across customer accounts. The write replaced only its own portion, leaving up to 60 KiB that could still hold whatever the previous container had written there. A raw read of the disk could then return bytes the new container never wrote.
The researchers used ext4 directory block checksums to tell their own blocks apart from everyone else's. Across six production placements, all 5,614 testable directory blocks came from elsewhere, with 2,700 distinct foreign directory inodes identified. Residual material appeared on 18 of 24 placements and 20 of 22 underlying nodes across four continents. Recovered block types included directory structures, database pages, and structurally complete SQLite databases.
Cloudflare is precise about the limits. An attacker could not choose a victim, a workload or a host, could not read an actively attached disk, and had no guarantee that residual data would be present at all. Exposure depended on where Cloudflare placed the workload and which released blocks dm-thin happened to reassign. The researchers did not demonstrate modification of another customer's data or any impact on availability.
Reaction among security practitioners on LinkedIn has focused on where the isolation broke rather than on the platform. Peter Ward, a senior cloud security engineer at Visa, described the pattern as a recurring one:
That is tenant isolation broken at the storage layer, not an app bug.
He argued that ephemeral disk and shared host warrant explicit zero-on-allocate or wipe-on-release checks in the control plane rather than network isolation alone, and offered a test teams can apply to any container or serverless platform: ask whether every reused volume path zeroes on allocate, and treat residual data on shared storage as a first-class isolation control.
Sherin Shahanas, a technology leader working in cloud and cybersecurity, made the point that the root cause is rarely verified:
"Isolated" is usually an architectural claim, not something independently tested at the storage layer.
His question for teams running shared infrastructure of any kind, whether containers, virtual machines or a shared virtualization cluster, was whether they know or merely assume that deallocated blocks are zeroed before reuse.
That question has arrived at a useful moment. The disclosure landed within days of two adjacent launches: Microsoft made Azure Container Apps Sandboxes generally available, describing each workload as running inside a hardware-isolated microVM boundary, and Google published benchmarks for GKE Pod snapshots, which checkpoint memory and disk through gVisor and store the result in Cloud Storage. Both vendors are selling isolation for agent workloads that execute untrusted code. Cloudflare's disclosure is a reminder that the guarantee spans every layer beneath the one named in the announcement, including the block allocator.
If these reactions are representative, the lesson practitioners are drawing is about verification rather than vendor choice. The Firecracker boundary held. What leaked sat below it, in a performance option that skipped zeroing on block reuse. Cloudflare's response was fast, and the timeline shows why the fix alone was insufficient. The report arrived at 15:26 UTC on September 4. 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 rolling out at 23:15 the same day. The rollout completed on September 7.
Removing skip_block_zeroing restored default behavior for newly allocated blocks, but it did not sanitize blocks already mapped into existing thin devices, whether in running container disks or in each host's cache of prepared snapshots for OCI image layers. A new 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. That cleanup completed on September 19.
On detection, Cloudflare says it built signatures from the characteristic pattern of a small write followed by a larger read, applied them to retained historical disk-I/O telemetry, and found only activity attributable to the researchers and to its own engineers conducting authorized validation.
The researchers confirmed that their proof of concept stopped working after the change, and that recovered data under their control was securely deleted following submission. Cloudflare awarded the bounty on September 14.