A vulnerability in Cloudflare Containers and the Sandboxes built on it could have exposed some data from other customers. Cloudflare received a report from a researcher on September 4, 2026, and said in a September 24 public post that it had fully fixed the vulnerability. Source
The key point for customers using these services is straightforward: Cloudflare says they do not need to change any settings or take additional action. The fix went beyond preventing the same issue on new disks. Cloudflare also cleaned up previously created disks and the image snapshot cache. Source
Does This Affect My Service?
The issue was found in Cloudflare Containers and the Sandboxes built on it. It involved how physical storage space for container disks was reused in a shared storage pool serving multiple customers. People who do not use these services should not take this to mean their data was exposed. Source
To understand the potential impact, it is important to distinguish between viewing another customer’s current work and seeing content left in previously used storage space. The method validated by the researcher could not target a specific victim, workload, or host, and it could not access disks in use. Residual data was not always found. Source
Why Could Previous Data Be Visible?
When disk space is allocated to a new container, previously used physical blocks may be reused. In this case, the skip_block_zeroing setting meant newly allocated blocks were not initialized. If new content was written to only part of a block and the rest was read, data left by a previous container could be exposed. Source
The potentially exposed content was not limited to an indication of empty space. It could include filesystem metadata and directory structures, database pages, and application data. By contrast, the ability to alter another customer’s active data or disrupt service availability was not demonstrated. The issue concerned the possibility of reading leftover information, rather than changing data. Source
What Did Cloudflare Change?
The first step was to remove the skip_block_zeroing setting so newly allocated blocks would be initialized. The researcher independently confirmed that the existing proof-of-concept method no longer worked after this change. This was intended to prevent previous content from being read in the same way when storage space is reused. Source
Changing the setting alone, however, could not remove existing mappings on disks already in use or in cached image snapshots. Cloudflare retired container disks, deleted its cache of prebuilt image snapshots, drained hosts in sequence, and restarted virtual machines. The company said it completed cleanup of cached snapshots from before the mitigation on September 19, 2026. Source
Was Customer Data Actually Exposed?
Cloudflare said its analysis of available historical disk I/O telemetry found no additional activity matching the technique beyond authorized validation by the researcher and its own engineers. It also said it had no evidence of a customer data compromise. That conclusion is based on Cloudflare’s analysis of the data it had; it should not be read as an absolute guarantee that no other activity was possible. Source
What Should Customers Check or Do Now?
If you use Containers or Sandboxes, the immediate question is whether you need to change any settings yourself. Cloudflare’s notice explicitly says no customer-side configuration changes or additional action are required. The fix was not something customers had to perform inside their containers: Cloudflare changed how storage space is allocated and cleaned up existing disks and caches. Source
There is no reason to conclude that every customer experienced a data breach, but the types of data that could potentially have been exposed should not be dismissed either. What Cloudflare has confirmed is that it initialized newly allocated blocks and cleaned up existing storage space. Its guidance to customers is to review the notice without making changes. Source