
Cloudflare patches cross-tenant data leak in Containers
Cloudflare fixed a Containers flaw that let researchers recover other customers' residual data from shared storage blocks, with no user action required.
Cloudflare has patched a significant cross-tenant data leakage vulnerability in its Containers service that, if actively exploited, could have allowed one customer to read residual files left behind from other customers’ containers on the same physical host. The flaw, reported by a security researcher through the company’s bug bounty programme, was fixed automatically and requires no action by Cloudflare users.
Cloudflare Containers is a feature included in the Workers Paid plan that lets developers run their applications inside lightweight, isolated environments known as containers. Companies building backend services, processing jobs, or running code execution platforms on Cloudflare’s infrastructure commonly use it. Each container is meant to be walled off from others, but the newly discovered weakness undermined that separation, raising concerns about the safety of multi-tenant cloud services for data-sensitive applications.
The issue was found by Oren Yomtov, a security researcher at technology company Accomplish, who submitted it to the HackerOne platform on September 4. Cloudflare’s subsequent disclosure explains that the problem existed in a shared storage pool that, in certain circumstances, skipped the process of zeroing (overwriting with zeros) reused 64 kibibyte (64 KiB) physical storage blocks before handing them to a new container.
Here is how the vulnerability worked. When a container is deleted, the thin volume that backs its root disk is removed and its physical blocks are returned to a shared pool that serves multiple customers. Normally, before those blocks are reallocated, they should be zeroed to wipe any leftover data. However, a configuration error caused zeroing to be skipped. The researchers then demonstrated that by writing only 4 KiB of data to an unused area of a freshly created container’s disk, they could force a reused 64 KiB physical block to be allocated. Because the zeroing was absent, only the 4 KiB they wrote would overwrite the block; the remaining 60 KiB would retain whatever information had been left by the previous customer’s container. This is essentially a classic uninitialised-memory problem, applied to persistent storage.
In their tests, Yomtov and his colleagues found residual material on 18 out of 24 container placements and across 20 of the 22 underlying physical nodes they examined. This leftover data included directory structures, database pages from the embedded, file-based database engine common in web applications, Chromium profile fragments, and files such as .env configuration files and credential files, all potentially readable by an attacker with a Workers Paid account on the same host.
Cloudflare notes that an attacker would not have had any control over which specific customer’s data they recovered, nor could they read an actively attached disk. The researcher’s scripts only performed checks that returned aggregate numbers of exposed blocks, without ever retrieving actual readable file contents. As a result, no real customer data was exposed during this research.
After fixing the configuration that was skipping block zeroing, Cloudflare retired existing container disks and cleared any cached snapshots that might still hold stale mappings. All mitigation work was completed by September 19. The company also examined internal logs, telemetry, and historical data and found no evidence that any customer data had been exposed via this method outside of the researcher’s controlled tests.
Because the patch was applied to Cloudflare’s infrastructure automatically, customers do not need to update anything or take any special steps to protect themselves from this specific flaw. For anyone running applications on shared cloud infrastructure, however, the incident underscores a broader lesson: the storage layer’s handling of deleted data is critical to multi-tenant security.
For website owners and businesses that host their sites or applications with a provider, the separation between customer environments is one of the most important safeguards. A hosting service designed with rigorous tenant isolation, such as AEU Hosting’s managed WordPress platform, ensures that one customer’s data cannot unintentionally bleed into another’s. When evaluating a hosting or cloud provider, it is wise to ask about how storage is sanitised between tenants and how quickly serious vulnerabilities are patched. No action is required for Cloudflare users in this case, but the underlying principle applies widely: always know how your provider handles the data of customers that share the same physical hardware.
So schützen Sie sich
- If you use Cloudflare Workers or Containers, no action is needed because the fix was applied automatically.
- Ask any cloud provider you use whether they zero out storage blocks between tenants to prevent data leakage.
- Regularly rotate credentials and passwords for databases and third-party services your applications rely on.
- Store sensitive files like .env configuration files in encrypted storage or a secrets manager, not in plain text on disk.
- Monitor your own hosting or application logs for unusual file access patterns, especially after a vendor announces a vulnerability.
Begriffe Erklärt
- container A lightweight, isolated environment for running an application, similar to a virtual machine but sharing the host’s operating system.
- zeroing Overwriting storage blocks with zeros before they are reused, which ensures that no old data remains readable.
- cross-tenant The situation where one customer’s data or activity becomes visible to or affects another customer on the same shared infrastructure.
- thin volume A storage volume that only uses physical disk space as data is written, instead of pre-allocating the full capacity upfront.
- residual data Leftover information from a previous user or process that remains on a storage medium after it has been freed.