Cloudflare fixed a cross-tenant disk exposure in Containers

Cloudflare disclosed a cross-tenant data-exposure vulnerability in its Containers platform on September 24. The same underlying storage path also affected Cloudflare Sandboxes, which run on Containers. A Workers Paid customer could potentially recover residual disk blocks left by a previous workload on the same host.

Cloudflare says it removed the unsafe configuration across the fleet, retired affected disks, cleared cached image snapshots, and found no evidence that anyone exploited the issue beyond the reporting researchers and its own validation work. The company says customers do not need to change their configuration.

How the Cloudflare Containers flaw worked

Containers used Linux device-mapper thin provisioning (dm-thin) with skip_block_zeroing enabled in the affected storage pools. A deleted container returned physical 64 KiB blocks to a pool shared by multiple customer accounts, but the next allocation did not necessarily clear those blocks first.

The proof of concept created a new container, wrote a 4 KiB block into selected filesystem regions, and read the full 64 KiB block back from the raw device. The untouched remainder could contain bytes from a former tenant. The researchers reported residual material on 18 of 24 placements and 20 of 22 underlying nodes across four continents, including directory structures, database pages, and structurally complete SQLite databases.

The attack could not select a particular victim or read an actively attached disk. Residual data was not guaranteed to be present, and the reported technique did not modify another customer’s live data or take a workload offline. Those constraints reduce predictability, but they do not remove the isolation failure: data from one tenant could cross into another tenant’s newly allocated storage.

Cloudflare’s remediation went beyond one configuration change

Cloudflare first removed skip_block_zeroing, which stopped the reported allocation pattern for new blocks. That was not sufficient for disks and cached image layers that already contained mappings created before the fix. The company therefore drained hosts, restarted the relevant virtual machines, retired running container disks, and removed cached snapshots.

The rollout began on September 4, the researchers confirmed that the proof of concept no longer worked on September 14, and Cloudflare completed cleanup of pre-mitigation cached snapshots on September 19. Cloudflare says its historical disk-I/O review found only activity attributable to the researchers and authorized internal testing.

What customers should verify

Cloudflare’s current disclosure does not require a customer-side patch or credential rotation. Teams using Containers, Sandboxes, or related execution services should still record the disclosure in their incident and vendor-risk history, confirm that their deployment dates overlap the affected period if that matters for governance, and review any customer-side telemetry available for unusual raw-disk access.

Do not describe this as a conventional container escape or claim that customer secrets were confirmed stolen. The evidence supports a residual-storage exposure that could reveal filesystem metadata and application data under specific placement and allocation conditions. Cloudflare reports no evidence of malicious exploitation, and no CVE or public remediation deadline is listed in the disclosure.

Evidence

Cloudflare’s technical disclosure is the primary source for the storage mechanism, scope, remediation timeline, and telemetry review. Independent coverage from Cyber Kendra reports the same dm-thin and block-reuse mechanism, affected product scope, and absence of evidence for exploitation beyond the researchers. The practical status is therefore: fixed by Cloudflare, no customer action requested, but worth retaining as a concrete reminder that multi-tenant isolation includes storage sanitization and cache lifecycle—not only process and VM boundaries.