On September 4, 2026, Oren Yomtov from Accomplish disclosed a vulnerability through Cloudflare's bug bounty program affecting Cloudflare Containers and Cloudflare Sandboxes. The company has completed remediation across its fleet, and investigation revealed no customer data compromise or signs of malicious abuse.

Cloudflare worked closely with Yomtov and the Accomplish security research team throughout the response. Their controlled testing and detailed analysis enabled rapid validation and remediation of the issue.

The vulnerability stemmed from how Cloudflare Containers allocate storage on multi-tenant infrastructure. Customers cannot select their underlying host, and workloads are automatically distributed across eligible servers. A researcher with a Workers Paid account demonstrated the ability to recover leftover disk blocks previously used by other Containers running on the same physical host. Critically, the technique could not target specific customers, workloads, hosts, or data, and residual information was not guaranteed to exist.

Cloudflare deployed the fix fleet-wide without requiring any customer configuration changes. Historical disk input-output telemetry showed no evidence of unauthorized exploitation, with detected activity limited to authorized testing by researchers and Cloudflare engineers.

Storage allocation mechanism

Cloudflare Containers leverage Linux device mapper thin provisioning to furnish each container with a writable root disk. Each container operates within a dedicated virtual machine running on the Firecracker hypervisor, which presents the disk as /dev/vdc.

Thin provisioning allocates physical storage only when a virtual disk writes to an unmapped region. The affected storage pools used 64 KiB thin-block sizing. When a container's root disk was deleted, its physical blocks returned to a shared pool serving multiple customer accounts.

The problematic pool configuration included the skip_block_zeroing option. With this setting enabled, dm-thin bypassed the zeroing of newly allocated blocks before making them accessible. When a previously-used 64 KiB block was reassigned, a full-block write would overwrite previous contents entirely. However, a smaller write would only modify the written portion, leaving the remainder potentially containing data from the block's former owner.

Exploitation technique

Reading an unmapped region of a new thin disk did not expose residual data, as dm-thin returned zeroes without allocating a physical block for unmapped regions.

The proof of concept identified 64 KiB-aligned regions matching free space in the guest's ext4 filesystem and wrote one aligned 4 KiB block into each region. When such a write reached an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. The 4 KiB write replaced only that portion of the block, and because block zeroing was disabled, the remaining 60 KiB could retain data from a previous container. A subsequent raw-device read could therefore observe bytes the new container had never written.

The proof of concept followed these steps:

  1. Create a container using 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. Examine only the portions not overwritten by the new container.

The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes. Although researchers recovered raw blocks to validate the issue, materials provided to Cloudflare contained no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values. The researchers confirmed they securely deleted the recovered data.

Validation methodology

Researchers used ext4 directory block checksums to distinguish blocks belonging to their test filesystem from blocks originating elsewhere. When ext4 uses the metadata_csum feature, directory block checksums incorporate values associated with the filesystem and inode.

Across six production placements, the researchers reported:

  • All 5,614 testable directory blocks
  • Zero blocks attributed to the researchers' filesystem
  • 2,700 distinct foreign directory inodes identified through checksum analysis

To validate the method, researchers tested it against blocks they had deliberately created and deleted in their controlled test filesystem. The method correctly attributed all 162 blocks to that filesystem.

Researchers ultimately observed residual material 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. Researchers reported using scripts that output only aggregate counts and format checks, not recovered file contents. Materials submitted to Cloudflare contained no recovered content values or third-party identifiers. Researchers subsequently confirmed that recovered data remained confidential and was securely deleted following submission, consistent with Cloudflare's HackerOne disclosure policy.

Potential impact

The vulnerability could have allowed a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers' Containers on the same underlying host. Successful exploitation would have crossed the tenant-isolation boundary and could disclose filesystem metadata, directory structures, database pages, and application data.

However, an attacker could not select a particular victim or access an actively attached disk. Exposure depended on Cloudflare's workload placement and which previously released blocks dm-thin reassigned. Researchers did not demonstrate modification of another customer's active data or impact to workload availability.

Remediation steps

Cloudflare's first mitigation was removing skip_block_zeroing from the dm-thin pool configuration across the fleet. This restored dm-thin's default behavior of clearing newly allocated blocks before exposing them to a container, stopping the reported technique. Researchers independently confirmed their proof of concept no longer functioned after this change.

Zeroing new allocations did not sanitize blocks already mapped into existing thin devices. These mappings existed 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 allocating those blocks again, allowing residual bytes in unused regions to remain readable through raw reads of /dev/vdc.

Cloudflare therefore retired all running container disks and removed cached image snapshots created before the mitigation. The company drained hosts during off-peak hours, restarted the VMs on each host, and cleared each host's image cache so that disks and cached layers were recreated using zeroed allocations. This cleanup has been completed across the Containers fleet.

Investigation findings

Cloudflare reviewed retained historical disk input-output telemetry from its container infrastructure, using the researchers' proof of concept and internal reproduction as reference activity. The proof of concept produced a characteristic relationship between writes and reads: when a 4 KiB write reached a previously unmapped region, it could trigger allocation of a reused 64 KiB storage block, and with zeroing disabled, the remaining 60 KiB could retain data from a previous container.

Using these characteristics, Cloudflare developed detection signatures and applied them to available historical telemetry. Activity attributable to researchers and Cloudflare engineers conducting authorized validation was identified, but no additional activity consistent with the reported technique was found. The company saw no evidence that this specific attack vector was exploited by anyone else.

Timeline

  1. September 4, 15:26 UTC: Oren Yomtov from Accomplish reported the issue through HackerOne.
  2. September 4, 18:45 UTC: Cloudflare opened a security incident and confirmed the production setup that caused the flaw.
  3. September 4, 21:27 UTC: Cloudflare merged the runtime fix and its reuse test.
  4. September 4, 22:03 UTC: Cloudflare merged the changes for new and live pools.
  5. September 4, 23:15 UTC: Cloudflare started rolling out the changes.
  6. September 7, 06:13 UTC: Cloudflare completed rolling out the changes and began clearing old pool data.
  7. September 14, 10:50 UTC: The researchers reported that their proof of concept had stopped working.
  8. September 14, 12:52 UTC: Cloudflare awarded the researcher a bounty.
  9. September 19, 15:03 UTC: Cloudflare completed cleanup of all pre-mitigation cached snapshots across the affected fleet.

Cloudflare has patched the vulnerability, and remediation requires no further action from customers. The company found no evidence of malicious actors abusing this vulnerability.