A significant security flaw in **Cloudflare Containers** allowed one customer to inadvertently read data previously stored by other customers' containers on the same shared physical server. The vulnerability, which **Cloudflare** has since patched, stemmed from how shared disk space was managed. Reported on September 4 by **Oren Yomtov** of the security firm **Accomplish** through **Cloudflare**'s bug bounty program, the issue specifically involved data left on disk space that earlier containers had used and subsequently relinquished. Importantly, this did not involve live workloads, and an attacker could not selectively target specific customers' data. **Cloudflare Containers** operate by running customer programs within isolated containers on servers shared across numerous accounts. **Cloudflare**, not the customer, determines server allocation. The flaw also impacted **Cloudflare Sandboxes**, a service built on **Containers** designed for securely executing untrusted code, including that generated by AI agents. ### The Root of the Vulnerability The problem resided in the configuration of shared disks. Each container is provisioned with a disk utilizing **Linux**'s thin provisioning feature, which allocates storage in 64-kilobyte blocks. When a container was deleted, its allocated blocks were returned to a shared pool accessible by other customer accounts. Crucially, this shared pool was configured to *skip* wiping blocks before reassigning them to new containers – a practice that typically defaults to wiping. Consequently, if a new container wrote only a small amount of data into a reused block, the remaining portion of that block could still contain data from the previous container. ### Proving the Leak To demonstrate the vulnerability, researchers wrote a mere four-kilobyte block into unused disk space. Upon reading the entire block back at the raw disk level, the remaining 60 kilobytes, which they had not written, still contained bytes from a prior container. Their production tests were conclusive: leftover material was found in 18 out of 24 attempts, each on a **Cloudflare**-chosen server, and on 20 out of 22 underlying machines across four continents. ### Exposed Data and Mitigation **Cloudflare** confirmed that the recovered blocks contained directory structures, database pages, and structurally complete **SQLite** databases. **Accomplish**'s own write-up further detailed findings such as directory listings, **Chromium** browser profiles, `.env` files, and credential files, all identified as belonging to other customers. The researchers emphasized that their analysis scripts only produced counts and format checks, never disclosing file contents, and that all submitted material to **Cloudflare** was devoid of third-party names, identifiers, credentials, or recovered content. **Cloudflare** verified that the recovered data was kept private and securely deleted post-submission. There was no indication that the flaw could modify live customer data or disrupt workloads. **Cloudflare** addressed the vulnerability in two phases. Initially, they re-enabled the wiping of newly allocated blocks, effectively neutralizing the reported method. The researchers confirmed on September 14 that their proof of concept was no longer functional. However, this initial fix did not cleanse blocks already mapped into active container disks or within each server's cache of prepared image layers, which new containers could still inherit and read. To fully remediate this, **Cloudflare** proceeded to retire all running container disks and clear these caches, performing server drains and restarts during off-peak hours. This comprehensive cleanup concluded on September 19, with the flaw disclosed five days later. ### No Evidence of External Exploitation **Cloudflare** conducted an exhaustive forensic analysis, building detection signatures from the researchers' proof of concept and their own attack simulations. These signatures were run against retained disk-activity records. The investigation found no evidence of this specific method being used by any party other than the researchers and **Cloudflare**'s authorized engineers. While **Cloudflare** confirmed no external exploitation, the exact duration of the exposure remains unclear as the company did not specify the time span of retained records or when the unsafe setting was initially implemented. **Accomplish** researchers separately noted that the same disk setup also affected **Cloudflare's Browser Run** product, though **Cloudflare**'s official disclosure focused on **Containers** and **Sandboxes**. This marks their sixth reported sandbox escape since July, following discoveries in **Anthropic's Claude Cowork** and **Claude Code**, **Cursor's** command-line tool, **Docker**, and **OpenAI's Codex**.