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

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.