Cloudflare patches cross-tenant data leak in Containers traced to unzeroed disk blocks

Cloudflare has fully remediated a cross-tenant data exposure vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes, a product built on Containers. According to the Cloudflare blog, the flaw was reported on September 4, 2026 by Oren Yomtov, a security researcher at Accomplish, through Cloudflare's bug bounty program. It could have allowed a customer with a Workers Paid account to recover residual disk blocks previously used by other customers' containers on the same host. Cloudflare states it has no evidence that customer data was compromised.

How the storage flaw worked

Cloudflare Containers run on multi-tenant infrastructure, with the platform automatically assigning workloads to eligible servers; customers cannot choose the underlying host. Each container receives a writable root disk implemented with Linux device mapper thin provisioning (dm-thin) and runs inside a dedicated Firecracker virtual machine, where the disk appears as /dev/vdc.

Thin provisioning hands out physical storage only when a virtual disk writes to a previously unmapped region, and the affected pools used a 64 KiB thin-block size. When a container's thin volume was deleted, its physical blocks returned to a pool shared by workloads from multiple customer accounts.

The key misconfiguration was the skip_block_zeroing option in the pool settings. With it enabled, dm-thin did not clear newly allocated blocks before exposing them. A write covering the full block replaced the old contents, but a smaller write changed only the written portion, leaving the remainder holding data from the block's previous owner. Simply reading an unmapped region returned zeroes without allocating anything, so the flaw required a write to trigger.

The proof of concept

As described by Cloudflare, the researcher created a container on a Workers Paid account, opened the raw root disk at /dev/vdc, and recorded a baseline read. The exploit then wrote one aligned 4 KiB block into each 64 KiB-aligned region corresponding to free space in the guest's ext4 filesystem. Each write forced dm-thin to allocate a fresh physical 64 KiB block from the shared pool but only overwrote 4 KiB of it, so a subsequent raw read could inspect the untouched 60 KiB.

To attribute recovered blocks, the researchers used ext4 directory block checksums enabled by the metadata_csum feature, which incorporate filesystem- and inode-specific values. Across six production placements, all 5,614 testable directory blocks belonged to foreign filesystems and none to their own, identifying 2,700 distinct foreign directory inodes. A control test against blocks they had deliberately created and deleted attributed all 162 correctly.

Residual material appeared on 18 of 24 placements across 20 of 22 underlying nodes spanning four continents, and recovered block types included directory structures, database pages, and structurally complete SQLite databases. Cloudflare emphasizes that the submitted materials contained only aggregate counts, offsets, sizes and truncated hash prefixes — no third-party filenames, identifiers, credentials, hostnames or recovered content values — and that the researchers confirmed the recovered data was securely deleted, consistent with the HackerOne disclosure policy.

Limits of the attack

The technique could not target a particular customer, workload, host or data, and residual data was not guaranteed to be present. An attacker could not access an actively attached disk, and the researchers did not demonstrate modification of another customer's live data or any impact on workload availability.

How Cloudflare fixed it

The first mitigation removed skip_block_zeroing from dm-thin pool configurations across the fleet, restoring the default behavior of clearing newly allocated blocks before exposing them to a container. The researchers independently confirmed that the proof of concept no longer worked after this change.

Because zeroing new allocations does not sanitize blocks already mapped into existing thin devices — including hosts' caches of prepared dm-thin snapshots for OCI image layers, which new containers could inherit without reallocating those blocks — Cloudflare also retired every running container disk and removed cached image snapshots created before the fix. Hosts were drained during off-peak hours, VMs were restarted, and image caches were cleared so disks and cached layers were rebuilt from zeroed allocations. That cleanup is complete across the Containers fleet, with no customer-side configuration changes required.

No evidence of exploitation

Cloudflare reviewed retained historical disk-I/O telemetry from its container infrastructure, using the researchers' proof of concept and an internal reproduction as reference patterns. The only activity attributable to the reported technique came from the researchers and Cloudflare engineers conducting authorized validation; the company found no indication of malicious exploitation.

Why it matters

The incident is a concrete example of how a single storage-layer performance option — skipping block zeroing — can quietly break tenant isolation on shared infrastructure. Raw-device access inside a guest VM is a standard, legitimate capability, which made this a realistic attack surface rather than a theoretical one. It also underlines the value of coordinated disclosure: a carefully scoped proof of concept with no exposed customer data let Cloudflare validate, fix and verify the issue quickly, and the two-stage remediation — correct the configuration, then purge every pre-existing mapping — is a useful template for any operator running thin-provisioned storage across tenants.