Cloudflare has patched a cross-tenant data exposure vulnerability in its Containers product that let a customer on a Workers Paid account recover residual disk data left behind by other customers' workloads on the same shared host. The company's post-mortem, published on its blog, says the flaw was reported by security researcher Oren Yomtov of Accomplish through Cloudflare's bug bounty program on September 4, 2026, and that Cloudflare found no evidence the technique was exploited by anyone outside the authorized research.
The root cause sits in the storage layer, not the container runtime itself. Cloudflare Containers run each workload inside a dedicated virtual machine powered by the Firecracker virtual machine monitor, with a writable root disk backed by Linux device mapper thin provisioning, or dm-thin, presented to the guest as /dev/vdc. The affected storage pools used a 64 KiB thin-block size and were configured with the skip_block_zeroing option, which tells dm-thin to skip clearing newly allocated blocks before handing them to a container. When a thin volume was deleted, its physical blocks returned to a pool shared across multiple customer accounts — and when one of those blocks was later reassigned, only the portion a new container actually wrote to was overwritten. The rest could still hold a previous tenant's bytes.
The proof of concept, as Cloudflare's post describes it, exploited that gap directly: create a container, open the raw root disk, identify 64 KiB-aligned regions corresponding to free space in the guest's ext4 filesystem, and write a single 4 KiB block into each one. That small write was enough to trigger dm-thin's allocation of the full 64 KiB block from the shared pool; a subsequent raw read of the un-overwritten 60 KiB could then surface data left behind by the block's previous tenant. To confirm the recovered material genuinely belonged to other customers rather than their own test filesystem, the researchers used ext4 directory block checksums — a technique Cloudflare's post says they validated by first testing it against 162 blocks they had deliberately created and deleted themselves, correctly attributing all 162 back to their own filesystem.
The scale of what the researchers actually recovered is the number that should worry anyone running shared container infrastructure: across six production placements, Cloudflare's post-mortem reports the team examined 5,614 testable directory blocks and identified 2,700 distinct foreign directory inodes through checksum analysis — none of which belonged to their own test filesystem. Residual material turned up on 18 of 24 placements and 20 of 22 underlying nodes spanning four continents, including directory structures, database pages, and, per the post, "structurally complete SQLite databases." Cloudflare says the materials submitted to it contained no recovered content values, filenames, credentials, or third-party identifiers, and that the researchers confirmed they securely deleted the recovered data after submission.
Cloudflare's fix had two parts, and the second is the part that shows how hard this class of bug is to fully close. The immediate mitigation was pulling skip_block_zeroing from the dm-thin pool configuration fleet-wide, restoring default zeroing of newly allocated blocks — a change the researchers independently confirmed broke their proof of concept. But zeroing new allocations didn't sanitize blocks already mapped into running container disks or cached in each host's prepared dm-thin snapshots of OCI image layers, since a new container could inherit those cached mappings without triggering fresh allocation. Cloudflare says it had to retire every running container disk and clear every host's image cache, draining hosts during off-peak hours and restarting VMs to force disks and cached layers to be recreated with zeroed allocations — a cleanup it says it completed across the fleet by September 19.
The exploit's limits matter as much as its reach: Cloudflare's post is explicit that the technique could not target a specific customer, workload, host, or data, that residual data was not guaranteed to be present, and that the researchers demonstrated no modification of another tenant's active data or impact to workload availability. Cloudflare says its review of historical disk-I/O telemetry, using detection signatures built from the reported technique's read/write pattern, found activity attributable only to the researchers and Cloudflare engineers conducting authorized validation.
The timeline is the part worth stealing for an incident-response runbook: report at 15:26 UTC on September 4, incident opened at 18:45, runtime fix merged by 21:27 the same day, fleet-wide rollout completed September 7, full cached-snapshot cleanup finished September 19. For any team running multi-tenant container infrastructure for AI workloads, the lesson isn't just "check your storage-pool zeroing defaults" — it's that a shared-host cleanup after a storage-layer fix has to account for every cache layer that could have inherited pre-mitigation state, not just the live fix itself.