A Cloudflare Containers Bug Let Customers Recover Other Tenants’ Leftover Disk Data

Cloudflare has patched a vulnerability in Cloudflare Containers that could have let a paying customer recover leftover disk data from other tenants’ containers running on the same physical server. The company disclosed the flaw on September 24 in a detailed technical post explaining how the bug worked, how a security researcher found it, and why the full cleanup across its fleet took roughly two weeks longer than the initial fix.

Security researcher Oren Yomtov of the Tel Aviv firm Accomplish reported the issue through Cloudflare’s bug bounty program on HackerOne on September 4. Cloudflare says it has “fully remediated the vulnerability” and found “no evidence that customer data has been compromised.” The flaw affected both Cloudflare Containers and Cloudflare Sandboxes, a code execution product built on top of Containers that Cloudflare’s own documentation lists “AI Code Execution” as the first use case for, alongside data analysis notebooks, development environments, and CI/CD systems.

How a Skipped Setting Left Storage Unwiped

Cloudflare Containers give each container a writable root disk using Linux’s device mapper thin provisioning, known as dm-thin, running inside a dedicated virtual machine powered by the Firecracker hypervisor. Firecracker presents that disk to the guest as /dev/vdc. Thin provisioning only allocates real physical storage the first time a write lands on a previously unmapped region of the virtual disk, and the affected storage pools used a 64 KiB block size for that allocation.

Normally, dm-thin zeroes out a newly allocated block before letting a container read it, so a customer never sees data left behind by whoever used that physical space before them. Cloudflare’s affected pools, however, were configured with a dm-thin option called skip_block_zeroing, which skips that step.

That single setting created the opening. Reading an unmapped region of a thin disk is normally safe: dm-thin just returns zeroes without allocating anything. But writing a small 4 KiB block into an unmapped, 64 KiB-aligned region forces dm-thin to allocate a full 64 KiB block from the shared pool, a block that had likely been freed by a different customer’s now-deleted container. With zeroing skipped, only the 4 KiB the customer actually wrote got replaced. The other 60 KiB kept whatever the previous tenant had left there. Reading the block back then returned the customer’s own data plus 60 KiB of someone else’s.

Yomtov’s proof of concept found free, 64 KiB-aligned regions inside his own test filesystem, wrote one small aligned block into each, and read the full block back to harvest the leftover 60 KiB.

What the Researchers Actually Recovered

To prove the recovered data belonged to other customers and not their own test setup, the researchers used ext4’s directory block checksums, which incorporate values tied to the specific filesystem and inode that created them. Testing across six production placements, they found that none of 5,614 testable directory blocks traced back to their own filesystem. Checksum analysis instead identified 2,700 distinct foreign directory inodes. The researchers validated the method’s accuracy first, deliberately creating and deleting 162 blocks in their own controlled test filesystem and confirming the technique correctly attributed every one of them.

Across a wider set of 24 placements on 22 underlying nodes spanning four continents, they observed residual material on 18 of the placements and 20 of the nodes. Cloudflare says the recovered block types included directory structures, database pages, and “structurally complete” SQLite databases. The security outlet Cyber Kendra, which independently reviewed the disclosure, reported that the researchers’ own testing also turned up Chromium browser profiles and files shaped like .env configuration files containing credentials.

Cloudflare is careful to note real limits on the bug’s practical danger. An attacker could not choose a specific victim, target a particular host, or read a disk that was actively attached to a running container. Exposure depended entirely on where Cloudflare’s scheduler happened to place a customer’s container and which previously freed block dm-thin handed it. The researchers did not demonstrate that they could modify another customer’s live data or affect a workload’s availability. Cloudflare also says the material the researchers actually submitted contained no filenames, credentials, hostnames, or recovered content values, only aggregate counts, format checks, and truncated hash prefixes, and that the researchers securely deleted the recovered data after submission under Cloudflare’s HackerOne disclosure policy.

The Patch Was Fast. The Full Cleanup Took Two Weeks.

Cloudflare’s published timeline shows an unusually fast initial response. Yomtov reported the bug at 15:26 UTC on September 4. Cloudflare opened a security incident and confirmed the production setup that caused it by 18:45 UTC the same day, merged a runtime fix just under three hours after that, and started rolling the change out fleet-wide by 23:15 UTC, all within about eight hours of the report landing.

But removing skip_block_zeroing only stopped new exploitation. It did not erase the risk already baked into the fleet. Cached OCI image layers turned out to be a second path to the same problem: a new container could inherit block mappings from a cached image layer without reallocating them, so unzeroed bytes sitting in unused regions, including ext4 free space, could still be read straight off /dev/vdc. Fixing that meant retiring every running container disk, removing image snapshots cached before the mitigation, draining hosts during off-peak hours, restarting virtual machines, and rebuilding each host’s image cache from zeroed allocations. Cloudflare says it finished that cleanup across the entire Containers fleet on September 19 at 15:03 UTC, fifteen days after the initial report. The researchers confirmed on September 14 that their proof of concept no longer worked, and Cloudflare awarded them a bounty that same day. No CVE identifier appears in Cloudflare’s write-up.

Cloudflare says it also reviewed retained historical disk I/O telemetry, using the write-then-read pattern from the proof of concept as a detection signature, and found no activity matching it beyond the researchers’ own testing and Cloudflare’s own authorized reproduction. The fix required no action from customers.

A Pattern, Not a One-Off

Cyber Kendra frames the Cloudflare bug as Accomplish’s sixth publicly disclosed sandbox or tenant-isolation escape since July. The five before it, per that reporting, were an attack chain called SharedRoot that let an unprivileged session inside Anthropic’s Claude Cowork escape its virtual machine (which Yomtov disclosed in July and which the Cloud Security Alliance later documented in its own research note), plus separate findings in Claude Code, Cursor CLI, Docker’s hypervisor-backed sandboxing, and OpenAI’s Codex coding agent sandbox.

Each of those targets is a system where one customer’s code, or increasingly an AI agent’s code, is supposed to run in a box that a different customer’s code cannot see into or out of. The Cloudflare bug is a variation on the same theme at the storage layer rather than the process or kernel layer: the isolation held everywhere except in what got left behind on disk after a container was already gone.