How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers

A security researcher reported a vulnerability in Cloudflare Containers and Sandboxes concerning cross-tenant data exposure on multi-tenant infrastructure. The vulnerability stemmed from the storage behavior of Linux device mapper thin provisioning (dm-thin), specifically when the `skipblockzeroing` option was enabled. This configuration allowed residual data from previously used blocks to potentially persist when new allocations occurred, even if a small write was performed.
Cloudflare remediated the issue by removing `skipblockzeroing` from the dm-thin pool configuration across the fleet, restoring default behavior where newly allocated blocks are zeroed. The vulnerability involved reading unmapped regions of thin disks to recover residual data, which could expose filesystem metadata, directory structures, and application data belonging to other tenants on the same host.
The investigation confirmed that the reported technique was used by researchers for authorized validation across several production placements, leading to the recovery of specific data types like directory structures and SQLite databases from 18 placements. Cloudflare implemented a comprehensive cleanup, including removing cached snapshots and restarting VMs, to ensure remediation and eliminate any lingering exposure.

* Oren Yomtov, a security researcher from Accomplish, reported a vulnerability on September 4, 2026.
* The vulnerability affected Cloudflare Containers and Cloudflare Sandboxes.
* The research demonstrated that a customer with a Workers Paid account could recover residual disk blocks previously used by other Containers on the same host.
* Container storage allocation used Linux device mapper thin provisioning (dm-thin).
* Thin provisioning allocated physical storage only upon writing to an unmapped region.
* The affected pool configuration included `skipblockzeroing`.
* With this setting, dm-thin skipped zeroing newly allocated blocks, allowing previously used data to remain in reassigned blocks.
* The exploit involved writing a small block to correspond to ext4 free space, which triggered allocation of a physical 64 KiB block, leaving residual data from the previous owner in the remaining space.
* Researchers recovered residual material on 18 placements and 20 underlying nodes across four continents.
* Mitigation involved removing `skipblockzeroing` from the dm-thin pool configuration across the fleet.
* Cloudflare found no evidence of malicious exploitation in historical disk-I/O telemetry attributable to the reported technique outside of authorized validation.

The narrative centers on the inherent tension between efficiency (thin provisioning) and security isolation in shared, multi-tenant environments. The vulnerability was not a flaw in the application logic but a consequence of a specific, seemingly benign configuration choice (`skipblockzeroing`) within the underlying storage layer (dm-thin). This exposes a systemic risk: when operational mechanisms are optimized for performance without enforcing strict isolation boundaries across tenants, residual data leakage becomes a latent possibility rather than an active exploit.
The validation phase highlights the difficulty in isolating true malicious intent from legitimate testing methodologies. The researchers successfully leveraged filesystem metadata checks to distinguish their proof-of-concept artifacts from actual system data, suggesting that the method itself is technically sound for exposing underlying storage behavior when the configuration allows it. The fact that historical telemetry showed no other activity consistent with the exploit mitigates immediate panic about ongoing abuse but raises questions about the pervasive risk of architectural assumptions.
The remediation involved both a configuration fix (disabling zeroing) and extensive cleanup, indicating that fixing the policy was insufficient; the state of the underlying infrastructure itself needed resetting to ensure absolute isolation. The implication for cognitive sovereignty lies in recognizing that security posture is often defined by default settings and low-level operational parameters, not just high-level code. How do we establish protocols where performance optimizations are inherently constrained by verifiable, irreversible isolation guarantees rather than optional configuration flags? What responsibilities do platform providers have in preventing latent, architectural vulnerabilities from existing across the entire estate, even when direct exploitation is absent?