Cloudflare Containers Flaw Could Expose Data From Other Customers’ Workloads

Cloudflare has addressed a cross-tenant data exposure vulnerability in its Containers platform that could have allowed one customer’s workload to recover residual data belonging to other customers on the same infrastructure.

This flaw also affected Cloudflare Sandboxes and the Browser Run service within Browser Rendering, both of which utilize the same underlying disk implementation.

Cloudflare Containers Flaw

The issue was reported on September 4, 2026, by Oren Yomtov from Accomplish through Cloudflare’s bug bounty program. Cloudflare announced that they had completed fleet-wide remediation and found no evidence that the vulnerability had been exploited maliciously. The company added that customers needed no action.

The vulnerability arose from Cloudflare’s use of Linux device mapper thin provisioning, known as dm-thin, for writable container root disks. Each Cloudflare Container operates within a dedicated Firecracker virtual machine, where its root disk is presented as /dev/vdc. The affected infrastructure used 64 KB thin-provisioning blocks shared across multiple customer accounts.

Cloudflare’s storage configuration had enabled the skip_block_zeroing option, which stopped dm-thin from clearing a physical block that had previously been used before reallocating it to another container.

Consequently, a newly assigned container could write a small amount of data to an unmapped region, leading dm-thin to allocate a recycled 64 KB block. Although the new write would replace part of the block, the untouched bytes could still contain data from a previous tenant.

Researchers showed that writing a 4 KB-aligned block into ext4 free-space regions could expose the remaining 60 KB of data in the reassigned block through a raw disk read.

This situation created a tenant-isolation failure where a customer with a Workers Paid account could potentially retrieve filesystem metadata, directory listings, SQLite database pages, Chromium profiles, .env files, and credential-related artifacts left by earlier workloads.

The proof-of-concept could not target a specific victim, customer, host, or active disk. The exposure relied on workload placement and whether a previously used disk block was reassigned to the attacker’s container. The researchers could not alter another customer’s data, access live disks, or disrupt service availability.

In controlled tests across six production placements, the researchers identified 2,700 distinct foreign directory inodes. They observed residual data on 18 of 24 placements spanning 20 of 22 underlying nodes across four continents.

They used ext4 directory checksums to differentiate foreign blocks from their own test data, limiting their submission to aggregate counts, offsets, checksums, and truncated hashes rather than third-party content.

Cloudflare’s mitigation efforts involved removing skip_block_zeroing from dm-thin pools, restoring the default block clearing before allocations are exposed to containers.

The company also retired existing container disks, drained hosts, restarted virtual machines, and deleted cached OCI image snapshots created before the configuration change. This was necessary because pre-existing mapped blocks and cached layers could still retain residual bytes, even after re-enabling block zeroing.

Cloudflare said its review of historical disk I/O telemetry detected only activity linked to the researchers and authorized internal validation. This incident shows that multi-tenant isolation can fail not only through hypervisor or container escapes but also through storage-layer data remanence and unsafe block-reuse configurations.

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