On September 4, 2026, security researcher Oren Yomtov of Accomplish reported a vulnerability in Cloudflare Containers and Cloudflare Sandboxes (the latter built on Containers) through Cloudflare's bug bounty program on HackerOne. Cloudflare remediated the flaw and states it has found no evidence of customer data compromise. The disclosure was prepared jointly with Yomtov and the Accomplish research team, whose testing helped Cloudflare validate the issue.

Storage architecture behind the flaw

Cloudflare Containers run on multi-tenant infrastructure with automatic workload placement; customers cannot choose the underlying host. Each container gets a writable root disk provisioned through Linux device mapper thin provisioning (dm-thin) and runs inside a dedicated Firecracker VM, which exposes the disk as /dev/vdc.

Under thin provisioning, physical storage is allocated only when a virtual disk writes to a previously unmapped region. The affected pools used a 64 KiB thin-block size. Deleting the thin volume behind a container's root disk returned its physical blocks to a pool shared across multiple customer accounts. That pool was configured with skip_block_zeroing, which suppresses zeroing of newly allocated blocks. On block reuse, a full 64 KiB write replaced the old contents entirely, but a smaller write touched only part of the block, leaving the rest intact from the block's prior owner.

How the exposure technique worked

Reading an unmapped region of a fresh thin disk returned zeros rather than residual bytes: dm-thin serves zeroes without allocating a physical block. To force allocation into reused space, the proof of concept located 64 KiB-aligned regions matching ext4 free space in the guest and wrote a single aligned 4 KiB block into each.

Each such write to an unmapped thin block caused dm-thin to draw a 64 KiB physical block from the shared pool. The 4 KiB write overwrote only its own portion; with zeroing disabled, the remaining 60 KiB could hold data from a previous container. A subsequent raw read of /dev/vdc could then surface bytes the new container had never written. The proof-of-concept sequence was:

  1. Create a container under a Workers Paid account.
  2. Open the writable root disk at /dev/vdc.
  3. Read the disk and record a baseline.
  4. Write one 4 KiB block into each selected 64 KiB region corresponding to ext4 free space.
  5. Read the resulting blocks again.
  6. Inspect only the portions the new container had not overwritten.

The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes. No third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values were provided to Cloudflare, and the researchers confirmed they securely deleted the recovered data.

Validation and scope of exposure

To separate blocks from their own test filesystem from foreign blocks, the researchers relied on ext4 directory block checksums. With the metadata_csum feature enabled, these checksums fold in values tied to the filesystem and inode. Across six production placements they reported 5,614 testable directory blocks, none attributed to their own filesystem, and 2,700 distinct foreign directory inodes identified through checksum analysis. Tested against 162 blocks created and then deleted in their controlled test filesystem, the method attributed every block correctly.

Residual material appeared on 18 of 24 placements and 20 of 22 underlying nodes spanning four continents. Recovered block types included directory structures, database pages, and structurally complete SQLite databases. The researchers' scripts emitted only aggregate counts and format checks, not file contents, and nothing containing recovered values or third-party identifiers reached Cloudflare. They later confirmed the recovered data stayed confidential and was securely deleted after submission, in line with Cloudflare's HackerOne disclosure policy.

Impact

Exploitation could have let a Workers Paid customer recover residual data from storage blocks previously used by other customers' Containers on the same host, crossing the tenant-isolation boundary. Filesystem metadata, directory structures, database pages, and application data could have been disclosed. However, an attacker could not choose a victim or reach an actively attached disk — exposure depended on workload placement and on which released blocks dm-thin reassigned. The researchers did not demonstrate modification of another customer's active data or any effect on workload availability.

Remediation

The first fix removed skip_block_zeroing from the dm-thin pool configuration fleet-wide, restoring default behavior in which newly allocated blocks are cleared before a container can see them. This broke the small-write/large-read path to residual data; the researchers independently confirmed that their proof of concept no longer functioned.

Zeroing on allocation did not, however, sanitize blocks already mapped into existing thin devices — mappings present in running container disks and in each host's cache of prepared dm-thin snapshots for OCI image layers. A new container could inherit mappings from a cached layer without reallocating blocks, leaving residual bytes in unused regions, including ext4 free space, readable via raw reads of /dev/vdc.

Cloudflare therefore retired all running container disks and removed cached image snapshots predating the mitigation. Hosts were drained during off-peak hours, the VMs on each host restarted, and image caches cleared so disks and cached layers were rebuilt from zeroed allocations. The cleanup is complete across the Containers fleet, and no customer-side configuration changes are required.

Investigation and findings

Cloudflare reviewed retained historical disk-I/O telemetry from its container infrastructure, using the proof of concept and an internal reproduction as reference activity. The technique left a characteristic write-to-read relationship: a 4 KiB write into previously unmapped space could bring in a reused 64 KiB block, and with zeroing off the other 60 KiB could still carry another container's bytes, so later reads returned far more data than the new container had written. From these characteristics, Cloudflare built detection signatures and applied them to the available telemetry. The only matching activity traced to the researchers and Cloudflare engineers performing authorized validation. No other activity consistent with the technique appeared, and there is no evidence this attack vector was exploited by anyone else.

Timeline

  • September 4, 15:26 UTC: Yomtov reports the issue via HackerOne.
  • September 4, 18:45 UTC: Cloudflare opens a security incident and confirms the production setup behind the flaw.
  • September 4, 21:27 UTC: runtime fix and reuse test merged.
  • September 4, 22:03 UTC: changes for new and live pools merged.
  • September 4, 23:15 UTC: rollout begins.
  • September 7, 06:13 UTC: rollout complete; old pool data cleanup begins.
  • September 14, 10:50 UTC: researchers report the proof of concept no longer works.
  • September 14, 12:52 UTC: bounty awarded.
  • September 19, 15:03 UTC: cleanup of all pre-mitigation cached snapshots across the affected fleet complete.