Researchers found leftover disk material on 18 of 24 production tests and on 20 of 22 underlying machines across four continents, according to Cloudflare and the researchers who reported the issue.
How thin provisioning let one customer's container read another's leftover data
The root cause was the way Cloudflare Containers built per-container disks. Each container received storage via Linux thin provisioning that allocates in 64‑kilobyte blocks. When a container was deleted, its blocks returned to a shared pool. That pool had been set to skip wiping a block before handing it to the next container — and wiping is normally the default.
Because the pool did not zero blocks on reallocation, a new container that wrote a small portion of a reused block left the remaining bytes intact. The researchers exploited this by writing a four‑kilobyte region and then reading the whole 64‑kilobyte block back at the raw disk level; the roughly 60 kilobytes they had not written often still contained data left behind by prior containers.
What the researchers found and how they tested it
The flaw was reported on September 4 by Oren Yomtov of the security firm Accomplish through Cloudflare's bug bounty program. In production tests on servers selected by Cloudflare, the researchers reported finding leftover material on 18 of 24 tries, and on 20 of 22 underlying machines spanning four continents.
Cloudflare said the recovered blocks contained directory structures, database pages, and structurally complete SQLite databases. The researchers' write‑up listed directory listings, SQLite databases, Chromium browser profiles, .env files, and credential files, and described them as other customers' files.
The researchers said their analysis scripts output only counts and format checks, not file contents, and that the material they sent Cloudflare contained no third‑party names, identifiers, credentials, or recovered content. They also confirmed the recovered data was kept private and securely deleted after submission, Cloudflare said. The researchers did not show that the flaw could change another customer's live data or take a workload offline.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildCloudflare's two‑step remediation and timeline
Cloudflare closed the issue in two steps. First, it turned wiping back on for newly handed‑out blocks, a change that the researchers confirmed on September 14 stopped their proof‑of‑concept method. Because that single change did not clean blocks already mapped into running container disks or already cached image layers that new containers could inherit, Cloudflare retired every running container disk and cleared those caches.
To remove remaining exposure, Cloudflare drained and restarted servers during quiet hours. The company said it finished that cleanup on September 19 and disclosed the flaw five days later. Cloudflare also said the fix was rolled out across its service and that customers need do nothing.
Cloudflare's investigation and its findings
After getting the report, Cloudflare built detection signatures from the researchers' proof of concept and from its own copy of the attack and ran those signatures against disk‑activity records it had retained. It reported finding only the researchers' and its own engineers' authorized testing, and said it saw no evidence that this specific method had been used by anyone else.
Cloudflare did not state in its account the time span of the retained records or when the unsafe setting was first put in place; the company therefore did not say how long the exposure might have lasted.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: Review thin‑provisioning and block‑zeroing defaults in shared‑storage setups and confirm vendor statements about remediation steps; Cloudflare's change — re‑enabling wiping and retiring mapped disks and caches — is the specific remedy applied here.
- Affected enterprises and procurement leaders: Note that Cloudflare said customers need to do nothing because the company performed the cleanup and detection; procurement reviews and contractual audits may still want confirmation of affected services, since the researchers reported the same disk setup affected another Cloudflare product they named.
- End users and the general public: Cloudflare and the researchers said the recovered material was from disk leftovers, not live workloads, and that the researchers deleted what they collected; Cloudflare reported no evidence of unauthorized use beyond the authorized tests it found.
The disclosure leaves one concrete question in the record: Cloudflare reported no evidence of third‑party use but did not state how far back its retained disk‑activity records go, so the period of potential exposure is not specified in the company's account. Meanwhile, the researchers described the finding as their sixth sandbox escape since July, and Cloudflare named Containers and Sandboxes as affected while their post did not mention the researchers' separate note about Browser Run.
