Cloudflare remediates cross-tenant container disk data exposure
Cloudflare has remediated a flaw in Cloudflare Containers that allowed a paying customer to recover residual disk data left by another customer’s deleted container on shared infrastructure. Cloudflare Sandboxes, a service built on Containers for running untrusted code including code written by AI agents, was also affected.
The issue was reported on September 4 through Cloudflare’s bug bounty programme by Oren Yomtov of Accomplish. Cloudflare completed its cleanup on September 19 and disclosed the vulnerability five days later. Customers do not need to take action, the company said.
How residual data became readable
Containers are scheduled by Cloudflare onto servers shared by multiple accounts. Their disks use Linux thin provisioning, which allocates storage in 64KB blocks. When a container was deleted, the blocks it had used returned to a pool shared across customer accounts.
That pool had been configured not to wipe a block before reassigning it, although wiping is normally the default. If a new container wrote a small amount of data to a reused block, the unwritten portion could still contain bytes from the previous container.
The researchers demonstrated the condition by writing a 4KB block into unused space and then reading the entire block at the raw-disk level. The remaining 60KB could contain older data. In production testing, they reported finding leftover material in 18 of 24 attempts, spanning 20 of 22 underlying machines selected by Cloudflare across four continents.
What testing recovered and what it did not show
Cloudflare said recovered blocks included directory structures, database pages and structurally complete SQLite databases. Accomplish also listed directory listings, Chromium browser profiles, .env files and credential files among the artefacts it identified as other customers’ files.
The researchers said their analysis scripts produced counts and format checks rather than file contents. They submitted no third-party names, identifiers, credentials or recovered content to Cloudflare, kept recovered data private and securely deleted it after reporting.
The reported method concerned data from previous workloads, not live container data. The researchers did not demonstrate the ability to modify another customer’s live data or take a workload offline. Cloudflare’s public notice named Containers and Sandboxes as affected; the researchers separately said the same disk configuration affected Browser Run.
Two remediation stages
Cloudflare first restored wiping for newly allocated blocks, stopping the reported technique. The researchers confirmed on September 14 that their proof of concept no longer worked. That change alone did not remove data already mapped into active container disks or held in each server’s prepared image-layer cache.
The company then retired every running container disk, cleared those caches, and drained and restarted servers during quiet hours. It also created detection signatures from the proof of concept and its own reproduction, then searched retained disk-activity records. Cloudflare found only authorized activity by the researchers and its engineers, while noting no evidence that this specific method had been used by anyone else.
The disclosure leaves the duration of exposure unspecified because Cloudflare did not state when the unsafe setting was introduced or the retention period for the records searched. For businesses using multi-tenant container services, the practical implication is to confirm that storage lifecycle controls cover block reuse, active disk mappings and cached image layers rather than relying on deletion alone.