Overview
Cloudflare has fixed a vulnerability in its Containers platform that could allow one customer’s container to recover residual disk data previously used by another customer on the same physical infrastructure. The issue also affected Cloudflare Sandboxes, which runs on the Containers platform and is designed to execute potentially untrusted workloads, including code generated by AI agents. Although there is no evidence that the vulnerability was maliciously exploited, the incident highlights one of the most important principles in cloud architecture: multi-tenancy depends on strong isolation not only between running workloads, but throughout the entire data lifecycle.
How the Vulnerability Worked
Cloudflare Containers used Linux thin provisioning to allocate storage in 64 KB blocks. When a container was removed, its storage blocks returned to a shared pool. However, the environment was configured to skip wiping those blocks before they were reassigned. If a new container wrote only a small portion of a reused block and then read the entire block directly, parts of the previous customer’s data could remain accessible. Researchers recovered material including directory structures, database pages and complete SQLite databases. Importantly, the vulnerability did not allow an attacker to select a particular customer or access an actively attached workload. The exposure depended on which previously used storage blocks happened to be reassigned.
The Bigger Multi-Tenant Security Question
Cloud platforms achieve enormous efficiency by sharing physical infrastructure across many customers. That model relies on strict logical isolation across compute, memory, networking and storage. A weakness at any of these layers can potentially cross the tenant boundary—even when the applications themselves are securely configured. This incident demonstrates that isolation cannot stop when a workload is deleted. Data sanitisation and resource reuse are equally important parts of cloud security.
Cloudflare’s Response
Cloudflare first restored automatic block wiping so newly allocated storage would be cleared before being assigned to another container. However, previously allocated blocks could still exist inside running container disks and cached image layers. The company therefore retired existing container disks, cleared cached snapshots and restarted infrastructure so affected storage was recreated using properly sanitised allocations. The remediation has been completed across the Containers fleet, with no customer-side configuration changes required.
Expert in the Cloud Insight
This vulnerability highlights a security boundary that is largely invisible to cloud customers. Cloud security discussions often focus on identity, encryption, configuration and application vulnerabilities. Yet underneath those controls sits another critical requirement: one tenant must never inherit another tenant’s data. In multi-tenant environments, secure deletion is not simply a storage-management function. It is part of the isolation architecture. The incident also reinforces the importance of understanding the shared-responsibility boundary. Customers can secure their applications, credentials and workloads, but some controls—such as physical resource reuse and storage sanitisation—remain entirely dependent on the cloud provider.
Cloud trust ultimately depends on what happens to data not only while a workload is running, but after that workload is gone.
Leave a Reply