Cloudflare Containers Flaw Exposed Other Customers' Leftover Disk Data

What happened

Cloudflare and the researchers who found the flaw have disclosed a cross-tenant data exposure in Cloudflare Containers. Per the Accomplish write-up and The Hacker News report, the root cause was disk thin provisioning configured to skip block wiping when blocks were reallocated between customer accounts.

The consequence follows directly. When a new container wrote only a small amount to a reused block, the unwritten remainder still held whatever the previous customer's workload had left there. This was residual data, not a live workload. Cloudflare says an attacker could not choose whose data they received.

What the researchers recovered

Oren Yomtov of Accomplish reported the issue on 4 September 2026. According to the write-up, the recovered material included:

• Directory structures and database pages
• Complete SQLite databases
• .env and credential files
• Chromium browser profiles

The researchers report that the technique worked in 18 of 24 production tests across servers on four continents, and that 20 of 22 underlying machines were affected. The affected products were Cloudflare Containers and Cloudflare Sandboxes, which are built on Containers. The researchers also note Browser Run as affected, but Cloudflare's own disclosure does not mention it.

Cloudflare's fix and response

Cloudflare describes a two-phase remediation. First, it re-enabled block wiping for new allocations, which it verified as working on 14 September. Second, it retired all running container disks and cleared server image caches during maintenance windows. The fix was completed on 19 September, and public disclosure followed on 24 September.

Cloudflare states that the specific method was used only by authorised testing, and that it found no evidence of exploitation in retained disk-activity records. It says customers need to take no action. The reporting we reviewed mentions no CVE.

Why it matters

Isolation failures in multi-tenant platforms rarely look like a dramatic escape. Here the compute boundary held, but the storage layer quietly broke the tenant boundary. The performance benefit of skipping a wipe was traded against a confidentiality guarantee that customers assumed existed.

The exposure is also relevant to AI workloads. Agent and code-execution sandboxes are often built on the same container primitives, and they routinely hold API keys, .env files and browser sessions. Residual data in such a sandbox can carry credentials that outlive the workload that created them.

Practical steps for security teams

1. 1Treat secrets that lived on shared-tenancy container disks as potentially exposed during the affected window, and rotate them if your risk appetite requires it. Cloudflare's statement is that no exploitation was found, so this is a judgement call, not a confirmed compromise.
2. 2Prefer short-lived, scoped credentials inside sandboxes so leftover data has a small blast radius.
3. 3Encrypt sensitive data at the application layer rather than relying on the platform to wipe storage.
4. 4Add residual-data checks, such as reading unwritten blocks in a fresh instance, to your cloud and sandbox assessments.