Understanding Cloudflare Containers: Why can deleted data still leak between customers?

Deleted data from a container does not necessarily disappear from the physical storage layer. A vulnerability in Cloudflare Containers has just been announced showing that configuring optimized performance at the drive level can weaken the boundaries of multi-customer isolation. The issue has been fixed throughout the system by Cloudflare, which says it has not detected evidence of unauthorized exploitation.

What is a Cloudflare Containers Vulnerability?

On September 4, 2026, Accomplish researcher Oren Yomtov reported through Cloudflare's bug bounty program that a customer using a paid Workers account can recover the remaining data blocks from another customer's container that used to run on the same physical server. Cloudflare Sandboxes, a service built on Containers to run unreliable code, was also affected.

This is an error cross-tenant data exposure, which means a data leak that crosses customer boundaries. The miner cannot select the specific victim, server, or workload; nor does the data obtained come from the drive being used by another container. However, reading any other tenant's data is still a serious violation of the cloud quarantine principle.

Thin provisioning and 64 KiB storage block

Cloudflare uses Linux device mapper thin provisioning (dm-thin) to grant the original writable drive to the container. Each container runs in a separate Firecracker virtual machine and sees this drive under the name /dev/vdc. Thin provisioning only allocates physical space when the virtual drive actually writes to the unmapped area, helping to use capacity more efficiently.

The affected storage pools use 64 KiB blocks. When a container is deleted, its physical blocks are returned to the shared pool for the workloads of multiple accounts. Reconfigure enable option skip_block_zeroingwas dm-thin do not write 0 to clean the old block before granting the new tenant.

Why can a single 4 KiB recording expose the old 60 KiB?

If the new container writes the entire 64 KiB block, the old data will be replaced. But proof of concept only writes 4 KiB to a blank area aligned to the 64 KiB boundary. This operation forces the system to issue a used physical block, while only the first 4 KiBs are overwritten. Because zeroing is ignored, the remaining 60 KiBs may still contain the previous owner's bytes.

A rough read of the whole device then allows the observation of the part of the data that the new container has never recorded. It is noteworthy that reading a completely unmapped area only returns zero; the researcher must actively activate the allocation by small writing before re-reading the larger block.

What types of data may be exposed?

In a controlled manufacturing trial, the team observed residual material in 18 of 24 placements and over 20 of 22 junior nodes on four continents. Identified blocks include directory structures, database pages, and unstructured SQLite databases.

The team said the analysis tool only outputs aggregate counts and format test results. Documentation submitted to Cloudflare does not contain file names, identifiers, credentials, or third-party content; recovery data is kept confidential and securely deleted after reporting.

Limits of mining methods

The vulnerability does not allow targeting a specific customer, does not access the drive attached to another workload, and does not demonstrate the ability to correct active data or cause service disruptions. The results depend on Cloudflare's placement algorithm and whether the pool has re-issued the correct block that used to contain the data.

These limits reduce the determinism of the attack but do not eliminate the risk. Environment files, tokens, session cookies, or database pages need only appear randomly in residual data to make a significant security impact.

How did Cloudflare fix it?

The first measure is to eliminate skip_block_zeroing across the entire fleet, restoring default behavior: every new level block must be cleaned before the container accesses. Accomplish confirms proof of concept is no longer active after this change.

However, zeroing only protects new allocations. The mapped blocks in the running container drive and the cached snapshot image may still contain old bytes. So Cloudflare continues to stop the entire container drive from running, clear the cache image, drain the server at off-peak hours, and initialize the storage layer. The cleanup was completed on 9/19.

Reaction time

• 4/9: Accomplish reports a bug; Cloudflare confirms the configuration causing the problem and starts deploying the fix.
• 7/9: Configuration changes are completed on the fleet, and the process of erasing the old pool data is started.
• 14/9: The researcher confirms the proof of concept has stopped working.
• 19/9: Cloudflare finishes deleting cached snapshots created before minification.
• 24/9: Cloudflare makes technical analysis public and insists customers don't need to change configurations.

Your needs

Cloudflare said the vulnerability has been patched on the service side so customers don't need to perform a technical action. The company built the signature discovered from the proof of concept, compared with the historical I/O telemetry kept and only saw the activities of the research team and the authorized Cloudflare engineer. There is no evidence that this method has been exploited by other parties.

However, organizations using container environments for secret handling should continue to apply centralized secret management, short-lived tokens, encrypt sensitive data, and rotate credentials when there are grounds for exposure. Control at the application layer helps limit the consequences if the infrastructure isolation layer fails.

Lessons on multi-customer isolation

The incident underscores that quarantine does not depend solely on containers or virtual machines. The entire underlying chain — memory, block device, cache image, and resource reuse mechanism — must have clear cleaning rules. An option that seems to relate only to performance can turn “deleted” data into data of the next tenant.

For cloud providers, testing should cover the entire life cycle of resource allocation, retrieval, and reallocation. For customers, the shared responsibility model still entails reducing the amount of secrets stored on local drives and designing systems on the assumption that an individual layer of defense may fail.

VNCyberS compiled from Cloudflare and The Hacker News