Cloudflare has fixed a cross-tenant data exposure issue in its Containers platform after a security researcher showed that residual disk blocks from other customers’ workloads could be recovered on shared hosts. The company says it found no evidence of malicious exploitation, but the disclosure highlights how a storage-layer setting, not the virtual machine boundary itself, created the weakness.
What Cloudflare says happened
The issue affected Cloudflare Containers, the platform that also underpins Cloudflare Sandboxes. According to the report, a customer on a Workers Paid account could recover leftover disk blocks from other tenants’ containers running on the same host.
Cloudflare traced the problem to the thin-provisioned storage layer beneath each container’s Firecracker virtual machine. The failure was not in the VM isolation boundary; it was in the allocator that managed reusable disk blocks.
How the exposure occurred
Each container ran inside a Firecracker VM with a writable root disk provisioned through Linux device mapper thin provisioning. The affected pools used a 64 KiB thin-block size and had skip_block_zeroing enabled, which means newly allocated blocks were not cleared before being exposed.
That detail mattered. Writing a single 4 KiB block into an unmapped area caused dm-thin to allocate a 64 KiB physical block from a pool shared across customer accounts. The write updated only the part the new container touched, while the rest of the block could still contain data left behind by the previous tenant. A raw read of the disk could then reveal bytes the new container never wrote.
What the researchers found
Oren Yomtov, a security researcher at Accomplish, reported the issue on September 4 through Cloudflare’s bug bounty program. Using ext4 directory block checksums to distinguish their own blocks from others, the researchers identified substantial amounts of residual data across production placements.
Cloudflare’s summary of the findings is striking: 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.
Why this was limited, but still serious
Cloudflare says the exposure had important limits. An attacker could not choose a specific victim, workload, or host, could not read an actively attached disk, and had no guarantee that residual data would be present at all. The leak depended on placement decisions and whether dm-thin reassigned a previously used block.
The researchers also did not show modification of another customer’s data or any availability impact. Even so, the incident is a reminder that multi-tenant security depends on more than network controls and VM boundaries; storage reuse policies matter too.
Cloudflare’s response and remediation
Cloudflare moved quickly once it received the report. The timeline it shared shows the company opened an incident at 18:45 UTC on September 4, merged a runtime fix at 21:27, merged changes for new and live pools at 22:03, and began rolling out the fix at 23:15 the same day. The rollout finished on September 7.
Removing skip_block_zeroing restored default behavior for newly allocated blocks, but that was not enough on its own. Existing mappings inside running container disks and each host’s cached image layers could still reference old blocks. To address that, Cloudflare 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.
What Cloudflare checked after the fix
Cloudflare says it built detection signatures from the pattern of a small write followed by a larger read, then applied those signatures to retained historical disk I/O telemetry. The company says it found only activity tied to the researchers and to its own engineers during authorized validation.
The proof of concept stopped working after the change, and Cloudflare says any recovered data under the researchers’ control was securely deleted after submission. The company also awarded the bug bounty on September 14.
Why security teams are paying attention
Reaction from security practitioners has focused less on Cloudflare as a vendor and more on the class of problem. The core lesson is that “isolated” is only as strong as the least obvious layer beneath it, especially when ephemeral disks and shared hosts are involved.
Peter Ward, a senior cloud security engineer at Visa, described the pattern as “tenant isolation broken at the storage layer, not an app bug.” He argued that ephemeral disk and shared host designs need explicit zero-on-allocate or wipe-on-release checks in the control plane, rather than relying on network isolation alone.
Sherin Shahanas, a technology leader working in cloud and cybersecurity, made a similar point: “Isolated” is usually an architectural claim, not something independently tested at the storage layer. Her takeaway for teams using containers, virtual machines, or shared virtualization clusters was simple: know whether deallocated blocks are actually zeroed before reuse, rather than assuming they are.
A reminder for multi-tenant platforms
- Isolation has to hold at the storage allocator level, not just at the VM boundary.
- Performance shortcuts such as skipping zeroing can create security gaps if reused blocks are exposed.
- Ephemeral workloads and snapshot caches deserve the same scrutiny as long-lived disks.
- Validation should include direct testing for residual data, not only architecture review.
A timely disclosure for container and sandbox providers
The timing of the disclosure is notable because it arrived within days of related cloud announcements. Microsoft made Azure Container Apps Sandboxes generally available, describing each workload as running inside a hardware-isolated microVM boundary. Google also published benchmarks for GKE Pod snapshots, which checkpoint memory and disk through gVisor and store the result in Cloud Storage.
Those products are aimed at agent workloads and other untrusted code. Cloudflare’s incident is a reminder that the security promise spans every layer below the feature that gets mentioned in the launch post, including the block allocator and its reuse behavior.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: October 5, 2026 at 10:33 pm
0 views
