How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers
- Source
- blog.cloudflare.com
- Date
Cloudflare published details of a cross-tenant vulnerability in its Containers and Sandboxes products. A paying customer could read residual disk blocks that other tenants had left behind on the same physical host, meaning data from one workload could leak into another. The issue was reported to Cloudflare responsibly, and the company says it is fully patched and that it found no evidence of exploitation. The relevance to AI builders is direct: Cloudflare Sandboxes are a common place to run agent-generated or untrusted code, and multi-tenant isolation is the property those users depend on most. Residual-data bugs are a classic failure in shared storage, where freed blocks are reassigned without being wiped. Teams running agents on any shared sandbox provider should avoid writing secrets or customer data to scratch disk where they can avoid it, and should ask providers how storage is scrubbed between tenants.

Context
Cloudflare traced its Containers data-exposure vulnerability to reused disk blocks that were not cleared before reassignment. A small write could allocate a larger previously used block while leaving some old contents readable. According to its incident report, this could expose another customer's residual data on the same host, although an attacker could not choose the victim.
Repair required both clearing newly allocated blocks and replacing existing container disks and cached image snapshots that could retain earlier mappings. The company says fleet cleanup finished on September 19, 2026, with no customer configuration changes required. Its retained telemetry showed no evidence of malicious exploitation; that finding is bounded by the historical records available.
- The flaw came from dm-thin storage pools configured with skip_block_zeroing: when a reused 64 KiB block received a smaller write, the rest of the block could still hold data from a previous container.
- The proof of concept wrote one 4 KiB block into each 64 KiB region of ext4 free space, forcing allocation of a reused block, then read the raw /dev/vdc device to see the 60 KiB it never wrote.
- The researchers found residual material on 18 of 24 placements and 20 of 22 nodes, including directory structures, database pages, and complete SQLite databases, but could not target a chosen customer or an attached disk.
- Cloudflare says turning block zeroing back on was not enough: blocks already mapped into running disks and cached image-layer snapshots stayed readable, so it drained hosts, restarted VMs, and cleared image caches.
- Cloudflare built detection signatures from the small-write, large-read pattern and ran them over retained disk-I/O telemetry, finding only activity from the researchers and its own engineers.
Checking sign-in…
Loading comments…


