Cloudflare has remediated a cross-tenant data exposure flaw in its Containers platform that allowed one customer’s workload to recover residual disk content previously belonging to another tenant. The issue also affected Cloudflare Sandboxes, which is built on the same service. Cloudflare says it found no evidence of malicious exploitation or customer compromise in the telemetry available for review.

The weakness was reported through HackerOne on September 4 by Accomplish researcher Oren Yomtov. Exploitation required a paid Workers account and did not let an attacker select a particular victim, machine or file. Even so, the ability to retrieve another customer’s data fragments crossed one of the most important security boundaries in a shared cloud platform.

The leak occurred below the container boundary

This was not a conventional container escape or a break from a virtual machine. Cloudflare isolates every Container in a dedicated Firecracker microVM, but the flaw lived in the storage pool backing each virtual disk. The writable root disk appears inside the guest as /dev/vdc, while Linux device-mapper thin provisioning allocates physical storage in 64 KiB blocks as needed.

The affected shared pools used an option called skip_block_zeroing. When a disk was deleted, its blocks returned to a pool shared across customer accounts. New allocations could then inherit bytes from a previous workload because the recycled physical blocks were not cleared before reuse.

Researchers demonstrated the problem by locating free, 64 KiB-aligned regions in the guest filesystem and writing only 4 KiB into each one. That small write caused the storage layer to allocate an entire recycled block but replace only the first portion. A raw-device read could expose the remaining 60 KiB, even though the new workload had never written those bytes.

Tests recovered filesystem and database fragments

Across six production placements, the team examined 5,614 usable directory blocks. None belonged to its own proof-of-concept filesystem, while 2,700 distinct foreign directory inodes were identified. Residual information appeared in 18 of 24 placements and on 20 of 22 underlying nodes spanning four continents.

The recovered material included directory structures, database pages and structurally complete SQLite databases. The technique could not read disks still attached to active workloads, alter another tenant’s live content or interrupt availability. Results also depended on Cloudflare’s scheduler and the allocator choosing blocks that happened to contain useful remnants, making collection opportunistic rather than targeted.

Those limitations reduce precision, not the sensitivity of the isolation failure. Filesystem metadata, application records, tokens or database content can all retain value after deletion. Multi-tenant systems therefore need sanitization guarantees at every layer, including storage abstractions below otherwise strong microVM boundaries.

Cloudflare replaced disks and cleared cached layers

Cloudflare first disabled skip_block_zeroing, returning dm-thin to behavior that clears a block before presenting it to a new allocation. That change prevented future reuse leaks but did not erase data already mapped into running disks or cached container-image snapshots.

The company then retired existing container disks, drained hosts, restarted virtual machines and cleared image caches. Accomplish subsequently confirmed that its proof of concept no longer worked. Cloudflare also created detections for the unusual pattern used in the attack: a series of small 4 KiB writes followed by much larger reads from newly allocated 64 KiB regions.

A historical review reportedly found only the authorized research activity and Cloudflare’s own validation. Absence of evidence in retained telemetry does not prove that no exposure ever occurred, but it is a meaningful finding when combined with the exploit’s noisy disk behavior and unpredictable placement.

Customer response should be risk-based

No configuration change is required from Containers or Sandboxes customers. Organizations should still consider what secrets or regulated data their workloads handled during the affected period and whether precautionary credential rotation fits their risk policy.

• Inventory secrets, tokens and databases processed in temporary container storage.
• Rotate high-impact credentials if exposure would create unacceptable consequences.
• Review Cloudflare notices and internal logs for unexplained workload or disk activity.
• Keep sensitive secrets outside writable images where dedicated secret-management controls are available.

The episode is a reminder that strong compute isolation does not automatically provide safe data lifecycle management. In a shared cloud, deleted blocks must be treated as sensitive until the infrastructure proves they have been securely cleared.