Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data
Cloudflare fixed a Containers flaw that exposed other customers' leftover disk data.
Cloudflare and researchers said a flaw in Cloudflare Containers, which also underlies Cloudflare Sandboxes, let a customer read data previous containers left on shared disks. Thin-provisioned 64 KB blocks were returned to a cross-account pool without wiping, so a 4 KB write still exposed the rest of a prior tenant's block. Production tests recovered leftovers on 18 of 24 attempts, including directory listings, SQLite databases, Chromium profiles, .env files, and credential files. Oren Yomtov of Accomplish reported it on September 4; Cloudflare restored wiping, cleared existing disks by September 19, and said retained logs showed only authorized testing.
- Reused 64 KB thin-provisioned blocks were handed out without wiping.
- Leftover data was recovered on 18 of 24 production attempts.
- Recovered material included SQLite databases, .env files, and credentials.
- Cloudflare restored wiping and finished disk cleanup on September 19.
- Retained logs showed only authorized researcher and Cloudflare testing.
Full article697 words · extracted from thehackernews.com · click to collapse
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.
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, according to Cloudflare. The company has fixed the flaw across its service and says customers need to do nothing.
Cloudflare Containers runs customers' programs inside containers on servers shared by many accounts, and Cloudflare, not the customer, picks the server. Cloudflare Sandboxes, which runs on Containers and is sold as a safe place to run untrusted code, including code written by AI agents, was affected too.
The flaw was reported on September 4 by Oren Yomtov of the security firm Accomplish, through Cloudflare's bug bounty program.
The problem was in how the shared disks were set up. Each container gets a disk built using a Linux feature called thin provisioning, which allocates storage in 64-kilobyte blocks. When a container was deleted, its blocks returned to a pool shared across customer accounts.
That pool was set to skip wiping a block before handing it to the next container, and 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.
To reach it, the researchers wrote a small four-kilobyte block into unused space and then read the whole block back at the raw disk level. The 60 kilobytes they had not written still held bytes from a previous container.
Across production tests, they 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 recovered blocks held directory structures, database pages, and structurally complete SQLite databases, Cloudflare said; the researchers' own write-up lists directory listings, SQLite databases, Chromium browser profiles, .env files, and credential files, and describes them as other customers' files.
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.
They also confirmed the recovered data was kept private and securely deleted after they submitted it, Cloudflare said. 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. It 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.
But 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. It finished that cleanup on September 19, and disclosed the flaw five days later.
Cloudflare said it looked for signs that anyone else had used the method. It built detection signatures from the researchers' proof of concept and its own copy of the attack and 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, though it did not state the time span or when the unsafe setting was first put in place, so how long the exposure lasted is not clear from its account.
The researchers, who separately say the same disk setup affected Cloudflare's Browser Run product, 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's post named Containers and Sandboxes as affected and did not mention Browser Run.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.