Cloudflare Fixes Cross-Tenant Data Exposure Vulnerability in Containers

Cloudflare has disclosed a vulnerability in its Containers infrastructure that could have allowed a Workers Paid customer to recover residual data from storage blocks previously used by another customer's container on the same underlying host.

The issue was responsibly reported by security researcher Oren Yomtov of Accomplish through Cloudflare's bug bounty programme on September 4, 2026. Cloudflare says it fully remediated the vulnerability and found no evidence that customer data was compromised or that the specific attack technique was used maliciously.

The vulnerability affected the storage layer supporting Cloudflare Containers and Cloudflare Sandboxes, which is built on Containers. Because Containers operate on multi-tenant infrastructure, storage isolation between customers is a critical security boundary.

Cloudflare said customers could not choose the underlying host assigned to their workloads. The reported technique also could not target a specific customer, workload, host or data, and residual information was not guaranteed to be present.

What caused the vulnerability?

The issue originated in the way Cloudflare used Linux device mapper thin provisioning, known as dm-thin, to provide writable root disks for Containers.

Each container operates inside a dedicated virtual machine using the Firecracker virtual machine monitor. The container's writable disk is presented to the virtual machine as /dev/vdc.

The affected storage pools used a 64 KiB thin-block size. Physical storage was allocated when a virtual disk wrote to a previously unmapped region. When a container's thin volume was deleted, its physical blocks could return to a shared storage pool serving workloads from multiple customer accounts.

The critical configuration involved the skip_block_zeroing option.

With this setting enabled, dm-thin did not automatically clear a newly allocated physical block before making it available to a container. As a result, if a previously used 64 KiB physical block was reassigned, a full-block write would replace its contents, but a smaller write would modify only part of the block.

The remaining portion could therefore contain data left by the block's previous owner.

How the proof of concept recovered residual data

The researchers found that simply reading an unmapped region of a new thin disk did not expose previous data. Instead, the proof of concept had to cause dm-thin to allocate a physical block.

The researchers identified 64 KiB-aligned areas associated with free space in an ext4 filesystem and wrote a single aligned 4 KiB block into each selected region.

That small write could cause a previously unmapped 64 KiB block to be allocated from the shared storage pool.

Only the 4 KiB portion was overwritten. With block zeroing disabled, the remaining 60 KiB could retain bytes from the block's previous use.

A subsequent raw-device read could then expose bytes that the new container itself had never written.

What researchers found during validation

Cloudflare's disclosure provides several details about the controlled validation performed by the researchers.

The researchers used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem from blocks that originated from other filesystems. The technique relied on the metadata_csum feature, where directory block checksums incorporate filesystem and inode-related values.

Across six production placements, the researchers reported:

• 5,614 testable directory blocks

• Zero attributed to their own filesystem

• 2,700 distinct foreign directory inodes identified through checksum analysis

The researchers also tested their attribution method against deliberately created and deleted blocks in their controlled environment. Cloudflare says the method correctly attributed all 162 blocks in that test.

Residual material was observed on 18 of 24 placements and 20 of 22 underlying nodes across four continents.

The recovered block types included directory structures, database pages and structurally complete SQLite databases. According to Cloudflare, the researchers used scripts that produced aggregate counts and format checks rather than recovered file contents.

Cloudflare also says the materials submitted during disclosure contained no recovered content values or third-party identifiers, and the researchers confirmed that recovered data under their control was securely deleted.

Potential impact on customer isolation

The vulnerability created a potential cross-tenant data exposure scenario.

A customer with a Workers Paid account could potentially recover residual storage data from blocks previously used by another customer's Container on the same underlying host.

The information potentially exposed could include filesystem metadata, directory structures, database pages and application data.

However, the attack had important limitations.

An attacker could not select a particular victim, choose a specific host or access an actively attached disk. Exposure depended on workload placement and whether previously released physical blocks were reassigned to the attacker's container.

The researchers also did not demonstrate modification of another customer's active data or an impact on workload availability.

This distinction is important when assessing the incident. The disclosure describes a data exposure vulnerability with a potentially serious tenant-isolation consequence, but it does not describe arbitrary access to active customer disks.

How Cloudflare mitigated the vulnerability

Cloudflare's first mitigation was to remove skip_block_zeroing from the affected dm-thin pool configuration across its fleet.

This restored the default behaviour of clearing newly allocated blocks before exposing them to a container. Cloudflare says this stopped the reported technique, and the researchers independently confirmed that their proof of concept no longer worked after the change.

However, Cloudflare found that changing the allocation behaviour alone was not sufficient.

Existing mappings could remain in running container disks and in host caches containing prepared dm-thin snapshots for OCI image layers. A new container could inherit mappings from a cached layer without causing the underlying blocks to be newly allocated and zeroed.

This meant residual bytes could potentially remain readable through raw reads of /dev/vdc even after the allocation configuration was changed.

Cloudflare therefore took additional remediation steps.

The company retired running container disks and removed cached image snapshots created before the mitigation. Hosts were drained during off-peak periods, virtual machines were restarted, and image caches were cleared so disks and cached layers could be recreated using zeroed allocations.

Cloudflare says this cleanup was completed across the Containers fleet.

Cloudflare found no evidence of malicious exploitation

Cloudflare also investigated whether other workloads had generated activity consistent with the reported exploitation technique.

The company reviewed retained historical disk-I/O telemetry from its container infrastructure. Researchers' proof-of-concept activity and Cloudflare's internal reproduction were used as reference patterns.

According to Cloudflare, the technique produced a characteristic relationship between small writes and subsequent reads. A 4 KiB write could trigger allocation of a reused 64 KiB storage block, while the remaining 60 KiB could retain data from the previous container when zeroing was disabled.

Cloudflare developed detection signatures based on these characteristics and applied them to the historical telemetry available to the company.

The company identified activity attributable to the researchers and Cloudflare engineers conducting authorised validation, but did not identify additional activity consistent with the reported technique.

Cloudflare therefore said it found no evidence that this specific attack vector had been exploited by anyone else.

No customer-side action required

Cloudflare says the vulnerability has been patched and that customers do not need to make configuration changes.

The company also says it found no evidence of malicious abuse of the vulnerability.

For customers, the disclosure is primarily relevant as a technical explanation of how the issue occurred and how Cloudflare addressed the underlying storage and caching conditions.

Additional details were not disclosed in the announcement.

A rapid response timeline

The disclosure shows a response that moved from initial reporting to mitigation and fleet-wide cleanup over several days.

September 4, 2026

• 15:26 UTC: Oren Yomtov reported the vulnerability through HackerOne.

• 18:45 UTC: Cloudflare opened a security incident and confirmed the production configuration involved.

• 21:27 UTC: Cloudflare merged the runtime fix and a reuse test.

• 22:03 UTC: Changes for new and live pools were merged.

• 23:15 UTC: Cloudflare began rolling out the changes.

September 7, 2026

Cloudflare completed the rollout and began clearing old pool data.

September 14, 2026

The researchers reported that their proof of concept no longer worked. Cloudflare awarded the researcher a bounty later that day.

September 19, 2026

Cloudflare completed cleanup of all pre-mitigation cached snapshots across the affected fleet.

What this incident highlights

The disclosure illustrates a broader cloud security challenge: tenant isolation depends not only on virtual machines and application-level controls, but also on the behaviour of the underlying storage system.

A logical container boundary can still depend on lower-level mechanisms such as block allocation, storage reuse, filesystem behaviour and caching.

In this case, the interaction between thin provisioning, shared physical blocks, partial writes and cached storage mappings created the conditions for residual data exposure.

For cloud infrastructure teams, the incident highlights the importance of examining storage reuse paths as part of multi-tenant isolation testing. It also shows why remediation may require more than changing a configuration setting. Existing mappings and cached resources may need to be retired or recreated before the previous state is fully removed.

These observations are an analysis of the technical details disclosed by Cloudflare, rather than additional claims from the company.