Security1 publisher3 min readPublished Updated
Cloudflare Containers handed new tenants disk blocks still holding other customers' data
Cloudflare fixed a Containers flaw that let paying customers read other tenants' leftover disk data, found on 18 of 24 production tries. Sandboxes, the product it sells for running untrusted and AI-written code, was affected too.
The Watch · Security desk
What happened
- Oren Yomtov of security firm Accomplish reported the Cloudflare Containers flaw through Cloudflare's bug bounty program on September 4.
- A disk-block pool shared across customer accounts was set to skip the usual wipe, so a new container's small writes left a deleted container's data in the rest of each block.
- The leftover data turned up on 20 of 22 underlying machines across four continents, with Cloudflare choosing the server for each try.
- The researchers' write-up lists SQLite databases, Chromium browser profiles, .env files and credential files among the other customers' files they recovered.
- Cloudflare says it has fixed the flaw across the service and that customers need to do nothing.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Teams whose containers wrote .env or credential files to disk have to decide for themselves whether to rotate them, since Cloudflare has not dated how long the unwiped pool was live.
- exposure Tenants running agent-written code on Sandboxes could not choose their server, so their deleted files sat in a pool any account landing on the same machine could read.
- contradiction The researchers say Browser Run shared the same disk setup, but Cloudflare's disclosure names only Containers and Sandboxes, so Browser Run users have only the researchers' account of their exposure.
Exploiting it took a paying account and two disk operations [1][9]. Thin provisioning builds each container's disk from 64-kilobyte blocks, and a deleted container's blocks went back to the shared pool [7]. The researchers wrote a four-kilobyte block into unused space, then read the whole block back at the raw disk level [9]. The 60 kilobytes they had not written still held bytes from a previous container [9].
Cloudflare's account puts limits on what came back. An attacker could not choose whose data they got, and the data came from disk space earlier containers had given up, not from any live workload, according to Cloudflare [2]. The researchers did not show that the flaw could change another customer's live data or take a workload offline [15]. Cloudflare describes the recovered blocks as directory structures, database pages and structurally complete SQLite databases [11]. Its description leaves out the Chromium profiles and credential files the researchers report [12].
Turning wiping back on stopped new leaks but left old ones in place. Cloudflare first re-enabled wiping for newly handed-out blocks, and on September 14 the researchers confirmed their proof of concept no longer worked [16]. That change did not clean blocks already mapped into running container disks or into each server's cache of prepared image layers, and a new container could inherit and read those [17]. So Cloudflare retired every running container disk and cleared the caches, draining and restarting servers during quiet hours [18]. The reported method was dead 10 days after the report [2]. Cloudflare finished the cleanup on September 19, five days after that [5]. Public disclosure followed on September 24, 20 days after the report [1][4].
To look for other users of the method, Cloudflare built detection signatures from the researchers' proof of concept and its own copy of the attack, then ran them against the disk-activity records it had kept [19]. The search turned up only authorized testing by the researchers and Cloudflare's engineers, and the company said it saw no evidence anyone else used this specific method [19]. It did not say how far back those records reach or when the no-wipe setting was first put in place, so the length of the exposure is not clear from its account [20].
Cloudflare's servers are shared by many accounts, and Cloudflare, not the customer, picks which one runs a container [4]. Sandboxes runs on Containers and is sold as a safe place to run untrusted code, including code written by AI agents [5]. The isolation that failed here sat under the container, in how the provider recycled storage across accounts [8].
The researchers handled the data narrowly, by their account. Their analysis scripts output only counts and format checks, and nothing they sent Cloudflare contained third-party names, identifiers, credentials or recovered content [13]. Cloudflare said they confirmed the recovered data was kept private and securely deleted [14].
The researchers call this 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 [22]. The pattern is one research team working through agent and container sandboxes, with Cloudflare the latest vendor on the list [22].
What to watch
- Whether Cloudflare publishes the time span of its retained disk-activity records and the date the no-wipe setting went in.
- Whether Cloudflare confirms or disputes that Browser Run used the same disk setup, and whether its September 19 cleanup covered it.
- The researchers' next sandbox write-up; the Cloudflare finding is their sixth since July.