On September 4, 2026, security researcher Oren Yomtov from Accomplish reported a vulnerability in Cloudflare Containers through the company's bug bounty program. Any customer on the Workers Paid plan could exploit it to read disk data left behind by other customers' containers that had run on the same underlying host.
Cloudflare confirmed the issue, applied a fleet-wide fix, and completed cleanup of all affected infrastructure by September 19. The company says it found no evidence that customer data was compromised or that the vulnerability was exploited by anyone other than the researchers and Cloudflare engineers conducting authorized validation.
How the vulnerability worked
Cloudflare Containers run workloads on multi-tenant infrastructure using Linux device mapper thin provisioning (dm-thin) with a 64 KiB thin-block size. Each container receives a writable root disk presented as /dev/vdc inside a Firecracker virtual machine.
The affected storage pools were configured with the skip_block_zeroing option, which caused dm-thin to skip zeroing newly allocated blocks before making them accessible. When a container's thin volume was deleted, its physical blocks returned to a shared pool serving multiple customer accounts.
The exploit worked by writing a single 4 KiB block into regions aligned to 64 KiB boundaries that mapped to unallocated space within the guest's ext4 filesystem. If that write hit an unmapped thin block, dm-thin drew a physical 64 KiB block from the shared pool. Only the first 4 KiB was overwritten, leaving the other 60 KiB intact — so those bytes could still belong to whatever container had used that block before. Reading the raw device afterward could therefore surface content the new container had never written itself.
Validation and scope
The researchers validated their findings using ext4 directory block checksums, which incorporate filesystem and inode values when the metadata_csum feature is enabled. Across six production placements, they tested 5,614 directory blocks and found zero attributable to their own test filesystem, while identifying 2,700 distinct foreign directory inodes through checksum analysis.
The method was validated against 162 deliberately created and deleted blocks in a controlled test filesystem, which were all correctly attributed. Across four continents, the researchers found leftover data in 18 of the 24 placements they tried, spread across 20 of 22 underlying nodes. Among the recovered material were directory structures, database pages, and SQLite databases that were structurally intact.
The researchers' proof-of-concept scripts were built to emit only summary tallies and structural checks, never the contents of any files they recovered. Nothing they handed to Cloudflare included actual recovered data values or identifiers belonging to other customers. After submitting the report, the researchers deleted everything they had recovered, in line with Cloudflare's HackerOne disclosure rules.
Impact and limitations
In theory, a Workers Paid customer could pull residual data across the tenant-isolation boundary — filesystem metadata, directory structures, database pages, and application data. Still, an attacker could not target a specific victim or open a disk that was actively in use. How much was exposed hinged on where Cloudflare scheduled workloads and which freed blocks dm-thin handed out next. The researchers showed no way to modify another customer's active data or affect workload availability.
Mitigation and cleanup
Cloudflare's first mitigation removed the skip_block_zeroing option from the dm-thin pool configuration across the fleet, so the storage layer went back to its standard practice of zeroing fresh blocks before any container could touch them. The researchers confirmed the fix had closed the hole.
Because wiping newly allocated blocks left untouched any blocks already attached to running thin devices, Cloudflare additionally took every running container disk out of service and discarded cached image snapshots that predated the mitigation. Cloudflare drained hosts during off-peak hours, rebooted each host's VMs, and purged each host's image cache, forcing disks and cached layers to be rebuilt from zeroed allocations. This cleanup was completed across the Containers fleet by September 19.
No evidence of exploitation
Cloudflare reviewed retained historical disk-I/O telemetry from its container infrastructure, using the researchers' proof of concept and internal reproduction as reference activity. The company developed detection signatures based on the characteristic relationship between writes and reads produced by the exploit technique.
When those signatures were run against the available telemetry, the only matches were activity from the researchers themselves and from Cloudflare engineers carrying out authorized validation; nothing else fit the reported technique. Beyond that, the company found no sign that anyone else had used this attack vector.
Timeline
- September 4, 15:26 UTC: Accomplish researcher Oren Yomtov filed the report via HackerOne.
- September 4, 18:45 UTC: Cloudflare opened a security incident and verified that the production configuration was behind the flaw.
- September 4, 21:27 UTC: The runtime fix, together with a test guarding against its reintroduction, was merged by Cloudflare.
- September 4, 22:03 UTC: Cloudflare merged the changes covering both newly created and existing pools.
- September 4, 23:15 UTC: Rollout of the changes began.
- September 7, 06:13 UTC: The rollout of Cloudflare's changes finished, and work to wipe data from the old pools got underway.
- September 14, 10:50 UTC: The researchers confirmed their exploit no longer worked.
- September 14, 12:52 UTC: A bug bounty was paid out.
- September 19, 15:03 UTC: The last cached snapshots from before the fix were cleared fleet-wide.
Our take
The rapid timeline — from disclosure to fleet-wide fix in three days and full cleanup in two weeks — reflects a mature incident response. The use of ext4 checksums for validation is a clever forensic technique that other multi-tenant platforms should study. However, the underlying configuration choice (skip_block_zeroing) suggests a performance optimization that bypassed a default safety control; operators of similar dm-thin deployments should audit their own pool settings.
