Cloudflare fixes a cross-tenant Containers data leak

Cloudflare has disclosed and patched a vulnerability that let a paying customer on its Containers platform pull fragments of disk data left behind by other tenants running on the same physical host. Sandboxes, the sandbox product built on Containers, was affected too.

Cloudflare says the flaw was reported on 4 September 2026 through its bug bounty programme and is now fully remediated across the Containers fleet, with no configuration changes needed on the customer side. The company says it has no evidence that customer data was compromised.

How a shared pool leaked

Containers run on multi-tenant infrastructure and customers cannot choose which host their workload lands on. Each container sits inside a Firecracker virtual machine with a writable root disk carved out of Linux device-mapper thin provisioning at a 64 KiB block size. The affected storage pools had an option called skip_block_zeroing switched on, so when a thin volume was deleted its physical blocks went back into a pool shared with other customers without being wiped. A full-block write replaced everything in a block; anything smaller left the untouched remainder readable.

The proof of concept was almost mundane. Create a container on a Workers Paid account, open the writable root disk at /dev/vdc, write one aligned 4 KiB block into each 64 KiB region matching free space in the guest's ext4 filesystem, then read the disk back and inspect the bytes the container never wrote. Thin provisioning with zeroing disabled did the rest.

What was actually recoverable

The researcher, Oren Yomtov of Accomplish, used ext4 directory block checksums to tell his own test filesystem's blocks apart from everyone else's. Across six production placements he counted 2,700 distinct foreign directory inodes, and residual material turned up on 18 of 24 placements and 20 of 22 underlying nodes across four continents. The recovered block types included directory structures, database pages and structurally complete SQLite databases. The submission contained no recovered content values or third-party identifiers, and the researchers confirmed they securely deleted the data afterwards.

Cloudflare is careful about the limits. An attacker could not select a victim, a workload, a host or a data set, could not touch an actively attached disk, and did not demonstrate changing another customer's live data or knocking a workload offline. Exposure depended on where Cloudflare placed workloads and which released blocks the allocator handed back.

The fix took two passes

The first fix removed skip_block_zeroing from the dm-thin pool configuration across the fleet, restoring the default behaviour of clearing blocks before exposing them. The researcher confirmed the proof of concept stopped working. That alone was not enough, because zeroing new allocations does not clean blocks already mapped into existing thin devices, including mappings sitting on running container disks and in each host's cache of prepared image-layer snapshots. Cloudflare also retired every running container disk and removed cached snapshots created before the mitigation, draining hosts off-peak, restarting the virtual machines and rebuilding each host's image cache from zeroed allocations.

No sign of exploitation

Cloudflare reviewed retained historical disk I/O telemetry for the write-then-read pattern its own reproduction produced. It says it found no evidence of malicious exploitation, and that the activity it could attribute to the technique came from the researcher and Cloudflare's own engineers during authorised validation. The disclosure was written up with Yomtov and the Accomplish team.

Our opinion

The bug itself is the least interesting part. Shared thin provisioning has been leaky in principle since it was invented, and any storage engineer will tell you that recycling blocks without zeroing them is a bet on nobody ever reading the leftovers. What matters is that the obvious patch was not the fix. Removing skip_block_zeroing closes the hole for new allocations and would satisfy almost any internal review, yet the blocks already mapped into running container disks and cached image-layer snapshots kept leaking until Cloudflare drained hosts and rebuilt them. That second-order failure is the part worth remembering the next time a provider tells you tenant isolation is an architectural guarantee, because here it was a configuration detail plus a cache invalidation problem. Credit where it is due as well: an aggregate-only proof of concept, a fleet-wide mitigation in three weeks and a named thank-you is exactly how a bug bounty is supposed to work.