Cloudflare Resolves Critical Cross-Tenant Data Leakage Flaw in Container Infrastructure

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.

The nature of the data recovered was particularly sensitive. Cloudflare confirmed that the leaked material included directory structures, database pages, and even structurally complete SQLite databases. The researchers’ own technical write-up went into further detail, noting the discovery of Chromium browser profiles, configuration files with the .env extension—which are frequently used to store sensitive API keys and environment variables—and various credential files. Essentially, these were the digital fingerprints and private configuration data of other customers who had previously run workloads on those specific servers.

Despite the sensitivity of the data, both Cloudflare and the researchers emphasized several limiting factors of the vulnerability. Crucially, the data did not come from "live" workloads. An attacker could not actively spy on a container that was currently running; they could only scavenge for "ghost" data left behind by containers that had already finished their tasks and been deleted. Furthermore, the vulnerability did not allow an attacker to target a specific victim. Because Cloudflare, not the customer, determines which server a container runs on, an attacker would essentially be playing a game of "digital beachcombing," picking up whatever fragments happened to be on the server they were randomly assigned.

The researchers at Accomplish acted in accordance with ethical disclosure guidelines, ensuring that no third-party data was permanently compromised. Their analysis scripts were designed to output only metadata, such as counts of files and format checks, rather than the actual contents of the recovered files. They reported that the information provided to Cloudflare during the bug bounty process contained no third-party names, identifiers, or actual credentials. Furthermore, Cloudflare confirmed that the researchers had securely deleted all recovered data once the report was submitted and verified. There was also no evidence suggesting that the flaw could be used to alter a live customer’s data or disrupt an ongoing workload.

Cloudflare’s remediation effort was a multi-stage process that reflected the complexity of its global network. The first step, taken shortly after the report was received, involved re-enabling the wiping feature for all newly allocated blocks. This effectively "closed the tap" on new data leaks. By September 14, the researchers confirmed that their initial proof-of-concept attack no longer worked. However, the fix was not as simple as changing a single setting. Even after the wiping was enabled for new blocks, there were still "poisoned" blocks already mapped into the disks of currently running containers or sitting in the servers’ local caches of prepared image layers.

To fully eliminate the risk, Cloudflare had to ensure that every existing block of storage was either wiped or retired. This required a massive logistical undertaking: the company had to retire every running container disk and clear the caches across its entire fleet of servers. This was achieved by "draining" servers—systematically moving workloads off of them—and restarting them during off-peak "quiet hours" to minimize service disruption. This comprehensive cleanup was finalized on September 19, and the formal public disclosure of the vulnerability followed five days later on September 24.

Following the fix, Cloudflare conducted a forensic investigation to determine if the vulnerability had been exploited by any malicious actors prior to the researchers’ report. The company’s security team developed detection signatures based on the researchers’ proof-of-concept and their own internal reproductions of the attack. They then scanned their historical disk-activity records for any signs of similar behavior. According to Cloudflare, this audit revealed only the authorized testing performed by the Accomplish researchers and Cloudflare’s own engineers. No evidence was found to suggest that any other party had discovered or utilized this specific method of data extraction.

While the investigation found no evidence of prior abuse, the total duration of the exposure remains somewhat unclear. Cloudflare’s audit was limited by the retention period of its disk-activity logs, and the company did not specify exactly when the unsafe configuration was first introduced into its production environment. This leaves a question mark over how long the "skip wiping" setting had been active before it was caught by the bug bounty program.

The researchers at Accomplish noted that this discovery is part of a broader trend in cloud security research focusing on sandbox escapes and cross-tenant isolation. This particular flaw marks the sixth time since July that the firm has successfully identified a way to escape or compromise a code sandbox. Their previous findings include vulnerabilities in Anthropic’s Claude Cowork and Claude Code, the command-line tool for the Cursor AI editor, Docker, and OpenAI’s Codex. The researchers also mentioned that the same disk configuration issue affected Cloudflare’s "Browser Run" product, though Cloudflare’s official post specifically highlighted Containers and Sandboxes as the impacted services.

As of the time of disclosure, Cloudflare has stated that the vulnerability is fully patched and that customers do not need to take any action, such as rotating keys or changing passwords, unless they have specific reasons to believe their data might have been exposed through other means. The incident serves as a stark reminder of the technical intricacies involved in cloud isolation. In the world of high-performance computing, where every microsecond and every kilobyte of overhead counts, a seemingly minor optimization—like skipping the zeroing of a disk block—can inadvertently create a significant security gap. Through the collaboration between independent researchers and the company’s internal security teams, the flaw was identified and mitigated before it could be exploited by malicious actors, demonstrating the ongoing value of the bug bounty model in securing global internet infrastructure.