Cloudflare Containers handed new tenants disk blocks still holding other customers' data

A flaw in Cloudflare Containers let a paying customer read data that other customers' containers had left behind on the same server, Cloudflare and the researchers who found it said on Thursday.

According to Cloudflare, the data came from disk space that earlier containers had used and given up, not from any live workload, and an attacker could not choose whose data they got.

Cloudflare Containers runs customers' programs inside containers on servers shared by many accounts, and Cloudflare, not the customer, picks the server.

The pool was set to skip wiping a block before handing it to the next container, though wiping is normally the default, so when a new container wrote only a small amount into a reused block, the rest of the block still held the previous container's data.

The researchers wrote a four-kilobyte block into unused space and read the whole block back at the raw disk level; the 60 kilobytes they had not written still held bytes from a previous container.

Cloudflare said the recovered blocks held directory structures, database pages, and structurally complete SQLite databases.

The researchers' write-up lists directory listings, SQLite databases, Chromium browser profiles, .env files, and credential files, and describes them as other customers' files.

Cloudflare first 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 no longer worked.

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.

Cloudflare retired every running container disk and cleared those caches, draining and restarting servers during quiet hours; it finished that cleanup on September 19 and disclosed the flaw five days later.

Cloudflare built detection signatures from the researchers' proof of concept and its own copy of the attack, ran them against the disk-activity records it had kept, 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.

The flaw was reported on September 4 by Oren Yomtov of the security firm Accomplish, through Cloudflare's bug bounty program.

Across production tests, the researchers reported finding leftover material on 18 of 24 tries, each on a server Cloudflare chose, and on 20 of 22 underlying machines across four continents.

The researchers reported that 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.

Cloudflare said the researchers confirmed the recovered data was kept private and securely deleted after they submitted it.

The researchers did not show that the flaw could change another customer's live data or take a workload offline.

The reported method stopped working 10 days after the September 4 report.

Cloudflare finished the cleanup five days after the researchers confirmed the proof of concept no longer worked.

Cloudflare did not state the time span of the records it retained or when the unsafe setting was first put in place, so how long the exposure lasted is not clear from its account.

The researchers described the flaw as their sixth escape from a code sandbox published since July, after findings in Anthropic's Claude Cowork and Claude Code, Cursor's command-line tool, Docker, and OpenAI's Codex.

Cloudflare disclosed the flaw on September 24.

Public disclosure came 20 days after the report.

The researchers separately say the same disk setup affected Cloudflare's Browser Run product; Cloudflare's post named Containers and Sandboxes as affected and did not mention Browser Run.