Cloudflare Discloses Cross-Tenant Disk Data Leak in Containers and Sandboxes, Finds No Evidence of Exploitation

Overview

Cloudflare has disclosed a vulnerability in its Containers and Sandboxes products that allowed a paying customer to recover residual disk data left behind by other customers’ deleted containers on the same shared server. In a post on its blog, Cloudflare said security researcher Oren Yomtov of Accomplish reported the issue on September 4, 2026 through its bug bounty program, and that the company “has fully remediated the vulnerability, and we have no evidence that customer data has been compromised,” according to Cloudflare.

What We Know

How the flaw worked

Cloudflare Containers run each customer workload inside a dedicated virtual machine powered by the Firecracker virtual machine monitor, which presents a writable root disk to the VM as /dev/vdc, according to Cloudflare. The underlying storage uses Linux’s device mapper thin provisioning system, known as dm-thin, with a 64 KiB block size; when a container’s thin volume is deleted, its physical blocks return to a pool shared by workloads belonging to multiple customer accounts, per the post.

The affected storage pools were configured with an option Cloudflare identified as skip_block_zeroing, which skips zeroing newly allocated blocks before making them accessible to a new container. As a result, a small write into a reused 64 KiB block would overwrite only part of it, leaving the remainder populated with data from whichever customer had used the block previously, Cloudflare said.

Yomtov’s proof of concept exploited this by identifying 64 KiB-aligned regions of free space inside a new container’s ext4 filesystem, writing a single 4 KiB block into each region, and then reading the full block back at the raw device level — recovering roughly 60 KiB of data the new container had never written, according to Cloudflare. The Hacker News reported the same mechanism, describing it as writing “a small four-kilobyte block into unused space” and reading “the entire block at raw disk level.”

Scale of the exposure

Testing across six production placements, the researchers examined 5,614 testable directory blocks and identified 2,700 distinct foreign directory inodes belonging to other customers through checksum analysis, Cloudflare said. They validated their detection method against 162 blocks in a controlled test filesystem, correctly attributing all of them to their own environment. In broader production testing, the researchers found leftover data on 18 of 24 placements and on 20 of 22 underlying server nodes spanning four continents, according to Cloudflare’s post.

The recovered material included directory structures, database pages, and complete SQLite databases, per Cloudflare. The Hacker News reported that the researchers’ documentation also listed directory listings, SQLite databases, Chromium profiles, environment files, and credential files recovered from other customers.

AI-tooling angle: Sandboxes and a pattern of prior findings

Cloudflare Sandboxes, which is built on top of Containers, was affected because it inherits the same storage architecture, Cloudflare said. The Hacker News described Sandboxes as “marketed for running untrusted code including AI-generated code.”

The Hacker News also reported that Yomtov and Accomplish separately identified the same underlying disk issue affecting Cloudflare’s Browser Run product, and that “Cloudflare’s announcement specified Containers and Sandboxes but did not mention Browser Run.” According to the outlet, this was the researchers’ “sixth sandbox escape finding published since July,” following prior discoveries in “Anthropic’s Claude Cowork and Claude Code, Cursor’s command-line tool, Docker, and OpenAI’s Codex,” per The Hacker News.

Remediation timeline

Cloudflare’s post lays out a minute-by-minute timeline. Yomtov reported the issue on September 4 at 15:26 UTC through HackerOne; Cloudflare opened a security incident and confirmed the production setup by 18:45 UTC that same day, merged a runtime fix by 21:27 UTC, merged pool configuration changes by 22:03 UTC, and began rolling out the changes at 23:15 UTC, according to the post. The rollout finished on September 7 at 06:13 UTC. Yomtov confirmed his proof of concept no longer worked on September 14 at 10:50 UTC, and Cloudflare awarded him a bounty at 12:52 UTC that day, per the timeline. Cloudflare said it completed cleanup of all pre-mitigation cached snapshots across the affected fleet on September 19 at 15:03 UTC.

Cloudflare’s blog post carries a publish date of September 24, 2026. That lines up with The Hacker News’ account, which reported that cleanup “completed September 19” and that “Cloudflare disclosed the vulnerability five days later.”

The fix itself came in two parts, according to Cloudflare. First, removing the skip_block_zeroing option restored dm-thin’s default behavior of clearing newly allocated blocks, which stopped the reported technique — a change Yomtov independently confirmed. Because already-mapped blocks in running container disks and cached image layers were not automatically sanitized by that change, Cloudflare said it also retired all running container disks, removed cached image snapshots created before the fix, and drained and restarted hosts during off-peak hours so that disks and cached layers would be recreated with zeroed allocations.

No evidence of exploitation

Cloudflare said it reviewed “retained historical disk-I/O telemetry” using both the researchers’ proof of concept and its own internal reproduction as reference points to build detection signatures. “We saw no evidence that this specific attack vector was exploited by anyone else,” the company wrote. Cloudflare said the fix requires no action from customers.

What We Don’t Know

Cloudflare’s post does not assign a CVE identifier to the vulnerability, and neither source cited a CVSS severity score. It is also unclear how long the skip_block_zeroing configuration had been in place before Yomtov’s report, since Cloudflare’s disclosure addresses only the results of the researchers’ testing sample — six production placements and 22 underlying nodes — rather than a full accounting of the fleet’s history. Cloudflare’s own post does not address the Browser Run product that The Hacker News reported was separately found to share the same underlying disk issue.