Cloudflare patches storage-layer data leak affecting container customers

Cloudflare has remediated a cross-tenant data exposure vulnerability in its Containers platform that allowed customers to potentially recover leftover disk content from other users' workloads running on shared infrastructure. The company reported no signs of malicious abuse and says the boundary isolation at the virtualization layer itself remained intact.

How the vulnerability worked#

The flaw lay not in application code or virtual machine boundaries, but in the underlying storage allocator. Cloudflare's containers run on Firecracker virtual machines with writable root disks provisioned through Linux device mapper thin provisioning. The affected configuration combined a 64 KB block size with a setting that skipped zeroing—meaning newly allocated blocks were not wiped before reuse.

When a container wrote a 4 KB block into previously unmapped storage, the allocator assigned a 64 KB physical block from a pool shared across customer accounts. That write would only overwrite its 4 KB portion, leaving up to 60 KB of uncleared data from whatever customer had used that block before. A direct disk read could then retrieve bytes the new container never wrote.

Researchers discovered the exposure by using ext4 directory checksums to distinguish their own data from others'. Testing across six production regions revealed that 2,700 distinct foreign directory inodes appeared in 5,614 testable directory blocks. Residual content surfaced on 18 of 24 placements and 20 of 22 underlying nodes globally, including complete SQLite databases and database pages.

Attacker constraints#

The vulnerability came with significant practical limits. An attacker could not target a specific victim, choose which workload to inspect, or control which host their container landed on. Exposure also required that the released blocks happened to be reassigned—there was no guarantee residual data would be present at all. The researchers did not demonstrate any ability to modify another customer's information or disrupt availability.

Swift remediation and cleanup#

Oren Yomtov, a security researcher at Accomplish, reported the issue on September 4 through Cloudflare's bug bounty program. Cloudflare opened an incident at 18:45 UTC that same day, merged a runtime fix by 21:27, and began rollout by 23:15. However, the configuration change alone was insufficient. Blocks already mapped into existing container disks and cached snapshots would persist without triggering a fresh allocation, so new containers could still inherit them.