Cloudflare Containers Storage Bug Exposed Prior Tenant Data

Cloudflare has fixed a flaw in its Cloudflare Containers service that allowed a paying customer to read leftover disk data left behind by other customers' containers on the same shared server. The company and the researcher who found the issue, Oren Yomtov of security firm Accomplish, disclosed the problem on Thursday. Cloudflare says the data came only from disk space that earlier containers had used and released, not from any live workload, and that an attacker could not choose whose data they received. The company has rolled out the fix across its service, so customers do not need to take any action.

Cloudflare Containers runs customers' programs inside isolated containers on servers shared by many accounts, with Cloudflare choosing which server a workload lands on. Cloudflare Sandboxes, which runs on top of Containers and is marketed as a safe place to run untrusted code, including code written by AI agents, was also affected. The flaw was reported through Cloudflare's bug bounty program on September 4. The root cause was in the way shared disks were configured. Each container receives a disk built with a Linux storage feature called thin provisioning, which hands out space in fixed 64-kilobyte blocks. When a container was deleted, its blocks returned to a shared pool available to all customer accounts. That pool was set to skip wiping a block before giving it to the next container, even though wiping is normally the default. As a result, if a new container wrote only a small amount of data into a reused block, the rest of the block still contained the previous container's data.

To prove the flaw, the researchers wrote a small four-kilobyte block into unused space and then read the entire 64-kilobyte block back at the raw disk level, which shows data before any file system rules hide it. The 60 kilobytes they had not written still held bytes from a previous container. In production tests, they found leftover material on 18 out of 24 attempts, each on a server Cloudflare chose, and on 20 out of 22 underlying machines across four continents. Cloudflare said the recovered blocks held directory structures, database pages, and structurally complete embedded database files, a widely used database format included in many applications. The researchers' own write-up added directory listings, Chromium browser profiles, .env files (plain-text files that often hold environment variables and secrets), and credential files, describing them as other customers' files. The researchers said their analysis scripts produced 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. The researchers did not show that the flaw could change another customer's live data or take a workload offline.

Cloudflare fixed the flaw in two steps. First, it turned wiping back on for newly handed-out blocks, which stopped the reported method; the researchers confirmed on September 14 that their proof of concept, a small test program demonstrating the flaw, no longer worked. However, that change did not clean blocks already mapped into running container disks or into each server's cache of prepared image layers, which a new container could inherit and read. So Cloudflare also retired every running container disk and cleared those caches, draining and restarting servers during quiet hours. The cleanup was completed on September 19, and Cloudflare disclosed the flaw five days later.

Cloudflare said it searched for signs that anyone else had used the method. The company built detection signatures from the researchers' proof of concept and from its own copy of the attack, then ran them against the disk-activity records it had kept. It found only the researchers' and its own engineers' authorized testing, and said it saw no evidence that this specific method was used by anyone else. That finding covers the records Cloudflare retained, but the company did not state the time span of those records or when the unsafe setting was first put in place, so it is not clear from its account how long the exposure lasted. Separately, the researchers said the same disk setup affected Cloudflare's Browser Run product, but Cloudflare's post named only Containers and Sandboxes as affected and did not mention Browser Run. The researchers described the flaw as their sixth escape from a code sandbox published since July, after earlier findings in Anthropic's Claude Cowork and Claude Code, Cursor's command-line tool, Docker, and OpenAI's Codex.

For website owners and IT teams, the incident is a reminder that shared infrastructure needs strict storage isolation and cleanup. If a provider reuses disk space without wiping it, one customer's old files or credentials can become readable by the next tenant. For organizations running websites or applications in shared environments, this disk hygiene matters; AEU Hosting offers managed WordPress hosting secured end to end, so customers can ask a provider directly about how it isolates and wipes storage between tenants before placing sensitive data on shared infrastructure.