Cloudflare fixed a cross-tenant vulnerability in Cloudflare Containers and Cloudflare Sandboxes after researchers from the Accomplish team demonstrated that a user with a Workers Paid account could recover residual portions of storage blocks previously used by containers belonging to other customers on the same host. Researcher Oren Yomtov reported the issue to the company on September 4, 2026, through its bug bounty program, and Cloudflare says it found no evidence that customer data was compromised.
How did the problem arise?
Containers relies on Linux device mapper thin provisioning to provide a writable root disk inside a virtual machine running through Firecracker. The affected storage pools used 64-kilobyte blocks with the skip_block_zeroing option enabled, meaning that reallocated blocks were not zeroed before being made available to a new container.
When only 4 kilobytes were written to part of a new block, the remaining 60 kilobytes could retain data from the previous owner. A subsequent read from the raw device /dev/vdc could reveal these bytes, even though the new container had never written them.
What did the test demonstrate?
The exploit did not allow the selection of a specific customer, container, or host, and the appearance of residual data was not guaranteed. Nevertheless, the researchers reported observing residual material in 18 of 24 tested locations and on 20 of 22 core nodes across four continents. The observed types included directory structures, database pages, and structurally complete SQLite databases.
The researchers used ext4 filesystem hashing tests and metadata to distinguish blocks from their experimental system from blocks originating from other filesystems. According to the published results, 2,700 foreign directory nodes were identified, while none of the 5,614 test directory blocks was attributed to the researchers' system. Cloudflare says the materials submitted to it did not include filenames, identifiers, credentials, or recovered content, and that the researchers securely deleted the data in their possession.
How did Cloudflare fix the flaw?
The company removed the skip_block_zeroing option from its dm-thin pool configurations, returning new blocks to the default behavior of zeroing them before making them available. The researchers independently confirmed that the proof of concept no longer worked after this change.
However, zeroing new allocations was not sufficient because some blocks were still associated with existing container disks or temporary snapshots of OCI image layers. Cloudflare therefore retired old container disks, removed snapshots cached before the fix, drained hosts, rebooted virtual machines, and cleaned the image cache. This cleanup was completed on September 19, 2026, while deployment of the core fix was completed on September 7.
Why does this matter?
The incident is significant because it shows that tenant isolation in cloud infrastructure does not depend on virtual machines alone; details of storage reuse and thin-provisioning behavior can create a channel for leaking inactive data. At the same time, the practical limitations were clear: the test could not target a specific victim or access an actually attached disk, and it did not demonstrate modifying another customer's data or affecting the availability of its workloads.
Cloudflare reviewed historical disk input/output measurement logs for a distinctive pattern combining 4-kilobyte writes with larger reads. It attributed activity consistent with this pattern to the researchers and its engineers during authorized validation, and found no additional activity indicating exploitation of the attack by another party. According to the company, Cloudflare customers do not need to take any action.