Cloudflare Containers handed tenants reused disk blocks that could hold other customers' data

A 4KiB write to unallocated space on a tenant's virtual disk caused Linux dm-thin to claim a 64KiB block from a physical pool that other tenants had used before ^[2]. The pool ran with skip_block_zeroing set, and the flag did exactly what its name says ^[2]. The tenant then read its own raw device, /dev/vdc, and got back the 60KiB it had not written ^[3]. After a 4KiB write, 60 of the block's 64KiB, or 93.75 percent, could belong to a previous tenant ^[1].

Cloudflare described the flaw in a post dated 2026-09-24, which was summarized on dev.to ^[16]. According to that summary, a fragment is only useful if it happens to hold sensitive material and can be interpreted and pieced back together ^[6]. The summary still rates the flaw High because it breaks the confidentiality boundary between tenants ^[15]. It also describes the testing on production infrastructure as authorized research ^[17].

The fix is careful work. Cloudflare turned on zero-initialization for new dm-thin allocations, and customers do not have to change any setting themselves ^[7]. Zeroing at allocation time does not erase blocks that were allocated before the change. So Cloudflare also discarded and recreated the pre-fix disks and cached snapshots ^[8].

Victims have little to inspect. Their containers may show no errors, and their standard logs may not record a read made against a block after it was reassigned to another tenant ^[10]. Their EDR generally cannot see a raw block read that happens inside someone else's container, and web and DNS logs will not show the reuse ^[11]. The summary names three main ways to confirm exposure: Cloudflare's notifications, the customer's usage period and an inventory of stored data ^[10].

Cloudflare found no evidence of malicious exploitation in the telemetry it retained. The summary notes that this does not rule out exploitation outside the retention period or beyond what the telemetry covers ^[9]. Rebuilding the disks stops new reads, but it cannot recall a fragment someone already copied ^[8]. I think any long-lived credential that sat in plaintext on Containers or Sandboxes storage during a customer's usage period should be rotated, and its recent use checked at the identity provider ^[13]. The summary's standing advice is to keep plaintext long-term credentials off both persistent and temporary storage, and to use short-lived credentials and encryption ^[12].