Cloudflare Containers Leaked Prior Customer Data via Unwiped 64KB Thin-Provisioned Blocks

The flaw stemmed from Linux thin provisioning on shared disks. When containers were deleted their blocks rejoined a cross-tenant pool that skipped the normal wipe step. Researchers from Accomplish triggered the issue by writing 4KB into a fresh block then reading the full 64KB at raw level, recovering intact remnants from other accounts. Cloudflare confirmed the method worked on 20 of 22 underlying hosts before remediation.

Evidence came from the September 4 bug-bounty report plus Cloudflare's internal disk-activity logs. Signatures built from the proof-of-concept matched only the researchers' and engineers' authorized tests. No third-party exploitation traces appeared in retained records, though the exact start date of the unsafe pool setting remains unspecified. Recovered artifacts included Chromium profiles and credential files without live workload interference.

The incident reveals a recurring pattern: multi-tenant storage defaults that favor allocation speed over sanitization. Similar reuse vectors have appeared in other container platforms when thin provisioning meets rapid instance churn. Cloudflare's two-phase fix—re-enabling wipes then draining all running disks and caches—illustrates the operational cost of retroactive cleanup at global scale.

Next steps include sustained monitoring of block-allocation telemetry and potential hardware-rooted attestation for new container images. Regulators and enterprise customers will likely demand explicit data-residency attestations for sandbox products such as Browser Run.