Cloudflare has resolved a defect in its container infrastructure that allowed one customer to access residual files left by others on shared servers. The issue, which involved leftover disk blocks not being properly wiped, posed a risk of unintentional data exposure, though it didn’t allow selective data theft or interference with active work.
What went wrong
The affected environment uses shared servers running Cloudflare Containers, and its Sandboxes product (used for executing untrusted code such as AI agent scripts) was also vulnerable. When containers are deleted, the system frees their disk space by returning storage blocks (in 64 KB chunks via a Linux thin provisioning setup) to a global pool meant to serve other containers. However, Cloudflare had disabled block wiping in that pool.
Without wiping, new containers writing only partial data into reclaimed blocks left behind content from prior tenants—meaning previous users’ files, database pages, directory trees, and sensitive configurations could persist in parts. Researchers testing this by writing to only part of a block and reading it back discovered leftover material over numerous trials across servers in multiple continents. The data included traces of SQLite databases, browser profile files, “.env” configuration files, and credentials—though testers only verified existence and format, never viewing real private content.
Fixes and cleanup
The flaw was reported September 4 by a researcher working through Cloudflare’s bug bounty program. Cloudflare’s remedial plan rolled out in two phases. First, they reactivated block wiping for all newly assigned blocks. By September 14, Proof-of-Concept attacks attempting the same method against newly assigned resource pools failed.
The second stage addressed existing risk. Cloudflare retired all running container disks and purged caches of premapped image layers stored on servers. This involved draining and rebooting servers during low-traffic hours. That work wrapped up on September 19; the vulnerability was disclosed publicly five days later.
Scope, impact, and visibility
Cloudflare says there are no signs the flaw was exploited in the wild beyond the authorized research tests. It reviewed disk activity logs using detection measures derived from the proof-of-concept and found no evidence of unauthorized access. However, Cloudflare did not clarify exactly when the unsafe disk configuration was first enabled, so how long customers may have been exposed remains uncertain.
Also impacted was another internal product called Browser Run, which shares the same disk allocation architecture. While Cloudflare explicitly confirmed Containers and Sandboxes were affected, it did not explicitly name Browser Run in its public disclosure.
This type of vulnerability is part of a wider pattern of recent escapes from code sandboxes—similar flaws have surfaced in several systems over the past few months—including those in Docker, other AI agent environments, and code execution tools.
Why this matters: shared infrastructure malware or misconfiguration risks grow with scale. Customers run workloads expecting isolation; flaws like this weaken that assurance. Going forward, users of shared container services—including AI workloads—should validate provider sandbox hygiene and supply chain precautions. For Cloudflare, this incident underscores both the importance of proactive security testing and the need for transparency about how long exposures persist.
