Cloudflare has recently addressed a significant security vulnerability within its containerized infrastructure that could have allowed a malicious user to access sensitive data belonging to other customers. The flaw, which was identified and reported by security researchers, centered on the way shared disk space was managed between different accounts operating on the same physical hardware. According to reports released by both Cloudflare and the research team on Thursday, the vulnerability resided in the Cloudflare Containers service, a platform designed to run customer programs in isolated environments. By exploiting this flaw, a paying customer could potentially read residual data left behind by previous occupants of the same server, highlighting the persistent challenges of maintaining absolute isolation in multi-tenant cloud environments.
The issue was specifically located in the storage allocation layer of Cloudflare’s infrastructure. Cloudflare Containers, and by extension the Cloudflare Sandboxes product—which is marketed as a secure environment for executing untrusted code, such as that generated by artificial intelligence agents—utilize a shared pool of resources to maximize efficiency. When one customer’s container is decommissioned, the resources it occupied are returned to a general pool to be reused by the next available workload. In this instance, the "hand-off" of disk space was not handled with the necessary level of data hygiene, creating a window for cross-tenant data exposure.
The discovery was made by Oren Yomtov, a security researcher with the firm Accomplish, who reported the findings through Cloudflare’s bug bounty program on September 4. The researchers discovered that the shared disks were configured using a common Linux kernel feature known as thin provisioning. This technology allows for the efficient allocation of storage by only using physical disk space when data is actually written, rather than pre-allocating large, empty chunks of storage. In Cloudflare’s setup, these disks were managed in 64-kilobyte blocks. The fundamental problem arose from a configuration setting that instructed the system to skip the "wiping" or "zeroing out" of these blocks before they were reassigned to a new customer.
In a standard, secure configuration, thin provisioning systems are usually set to overwrite or zero out any previously used block before it is presented to a new user. This ensures that the new tenant starts with a "clean slate." However, Cloudflare’s implementation had this default safety feature disabled. Consequently, when a new container was spun up and began writing its own data, if it only wrote a small amount—for example, four kilobytes—into a newly assigned 64-kilobyte block, the remaining 60 kilobytes of that block would still contain whatever data had been stored there by the previous tenant.

To demonstrate the severity of the flaw, the researchers from Accomplish developed a proof-of-concept attack. Their method involved writing a very small amount of data to a disk and then performing a "raw" read of the entire block at the disk level. By reading the raw bytes rather than just the files visible through the standard operating system interface, they were able to see the data remnants that had not been overwritten. The results of their production tests were startling: out of 24 attempts conducted on servers randomly assigned by Cloudflare’s load balancers, the researchers successfully recovered leftover material in 18 instances. These tests spanned a wide geographic range, with successful data recovery occurring on 20 out of 22 machines tested across four different continents.
