Cloudflare has remediated a cross-tenant data exposure vulnerability in its Containers platform that could have allowed one customer’s workload to recover residual disk data belonging to other customers sharing the same physical host.
The flaw also affected Cloudflare Sandboxes and Browser Run, both of which rely on the same underlying Containers disk implementation.
Security researcher Oren Yomtov of Accomplish responsibly disclosed the issue through Cloudflare’s HackerOne bug bounty program on September 4, 2026.
Cloudflare Sandbox Escape Flaw
Cloudflare said it found no evidence of malicious exploitation or customer data compromise after reviewing retained disk-I/O telemetry, and it completed fleet-wide remediation without requiring customer configuration changes.
The issue was not a conventional container breakout or Firecracker microVM escape. Instead, it originated in the way Cloudflare provisioned storage for container root disks.
Cloudflare runs every Container in a dedicated Firecracker microVM and presents its writable root disk as /dev/vdc.
The platform uses Linux device mapper thin provisioning, known as dm-thin, to assign physical storage only when a virtual disk writes to an unmapped region. The affected pools used 64 KiB thin-provisioning blocks.
A configuration setting, skip_block_zeroing, prevented dm-thin from clearing a newly allocated physical block before exposing it to a new container.
Once a container disk was deleted, the physical blocks backing it returned to a shared pool that could later serve a different customer.
If the reassigned block contained previous tenant data and a new container made only a partial write, unwritten portions could still expose residual bytes.
The proof of concept identified 64 KiB-aligned areas of free space in a guest ext4 filesystem and wrote only 4 KiB into each region. That forced dm-thin to allocate a recycled 64 KiB block, but only the written 4 KiB was replaced.
The remaining 60 KiB could retain data from a prior workload and become readable through raw reads of /dev/vdc.
Checksum analysis showed that recovered filesystem structures did not belong to the researchers’ own test environment.
Across six production placements, the team examined 5,614 testable directory blocks, identified zero blocks attributable to its proof-of-concept filesystem, and detected 2,700 distinct foreign directory inodes.
Residual data appeared across 18 of 24 placements and 20 of 22 underlying nodes in four continents. Observed material included directory structures, database pages, SQLite databases, Chromium profiles, .env files, and credential files, according to Accomplish.
The attack was opportunistic rather than targeted. An attacker needed a Workers Paid account but could not select a particular victim, workload, host, or specific data. It also could not access actively attached disks, alter another customer’s live data, or affect workload availability.
Cloudflare first removed skip_block_zeroing across its Containers fleet, restoring dm-thin’s default behavior of clearing newly allocated blocks before making them available to a container.
The company then retired existing container disks, drained hosts, restarted virtual machines, and cleared cached OCI image snapshots.
This additional cleanup was necessary because previously mapped blocks could remain accessible through running disks or image-layer caches even after block zeroing was restored.
Cloudflare also developed detections for the anomalous I/O sequence used in the proof of concept: a small 4 KiB write to trigger allocation, followed by substantially larger reads from the allocated 64 KiB block.
Although Cloudflare says customers need to take no action, organizations that processed highly sensitive secrets, credentials, tokens, or application databases in affected workloads may want to assess whether precautionary credential rotation aligns with their risk policies.
The incident highlights that strong VM and container isolation can still be undermined by storage lifecycle errors in multi-tenant environments.
Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team
