Cloudflare Containers Vulnerability Could Leak Data Between Customer Workloads

Cloudflare has patched a cross-tenant data exposure vulnerability in its Containers platform across its global, multi-tenant cloud computing infrastructure that could allow one customer’s workload to recover residual disk data left by another tenant on the same physical host.

The issue also affected Cloudflare Sandboxes, which is built on Containers, but Cloudflare says it found no evidence of malicious exploitation or customer data compromise in its retained telemetry.

Oren Yomtov, a security researcher at Accomplish, responsibly disclosed the flaw through Cloudflare’s HackerOne bug bounty program on September 4, 2026.

Exploitation required a Workers Paid account, and Cloudflare’s automatic workload placement meant an attacker could not choose a victim, host, workload, or specific information. Nevertheless, the weakness crossed a critical tenant-isolation boundary in shared cloud infrastructure.

Cloudflare Containers Vulnerability

The vulnerability originated in the storage layer rather than a conventional container or virtual-machine escape. Cloudflare runs every Container inside a dedicated Firecracker microVM and exposes its writable root disk as /dev/vdc.

Behind that disk, Linux device mapper thin provisioning, or dm-thin, allocates physical storage in 64 KiB blocks only when the virtual disk writes to an unmapped region.

Cloudflare’s affected shared storage pools enabled the skip_block_zeroing option. When a container disk was deleted, its physical blocks returned to a pool used by multiple customer accounts. Because new allocations were not cleared, a recycled block could retain bytes belonging to its previous owner until those areas were overwritten.

The researchers exploited this behavior by identifying 64 KiB-aligned regions representing free space in the guest’s ext4 filesystem and writing only 4 KiB into each region. That small write forced dm-thin to allocate a recycled 64 KiB block while replacing just 4 KiB.

A subsequent raw-device read could reveal residual data in the untouched 60 KiB—bytes the new container had never written.

Checksum analysis provided evidence that the exposed blocks came from other filesystems. Across six production placements, the team examined 5,614 testable directory blocks and attributed none to its own proof-of-concept filesystem, while identifying 2,700 distinct foreign directory inodes.

Residual material appeared on 18 of 24 placements and 20 of 22 underlying nodes spanning four continents. Observed formats included directory structures, database pages, and structurally complete SQLite databases.

The technique did not provide access to actively attached disks, permit modification of another customer’s live data, or affect workload availability. Results also depended on scheduling and which freed blocks the allocator reassigned, making extraction opportunistic rather than targeted. Even with those limitations, exposed fragments could potentially contain filesystem metadata, application information, or sensitive database content.

Cloudflare first removed skip_block_zeroing across the Containers fleet, restoring dm-thin’s default behavior of clearing newly allocated blocks before exposing them.

Because this change did not sanitize blocks already mapped into running disks or cached OCI image snapshots, the company also retired existing container disks, drained hosts, restarted virtual machines, and cleared image caches. The researchers independently confirmed that their proof of concept stopped working.

Cloudflare then developed detection signatures around the attack’s unusual disk-I/O pattern: small 4 KiB writes followed by substantially larger reads from newly allocated 64 KiB blocks.

Its historical review found only activity linked to Accomplish’s researchers and Cloudflare engineers performing authorized validation. The fleet-wide remediation requires no customer configuration changes, although organizations should assess whether secrets handled by affected workloads warrant precautionary rotation under their own risk policies.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC