Cloudflare Resolves Cross-Tenant Data Exposure in Container Platform

This configuration combination created the security gap. Writing a single 4 KiB block to an unmapped area caused dm-thin to allocate a 64 KiB physical block from a resource pool shared across customer accounts. The write operation only covered the 4 KiB space it occupied, leaving up to 60 KiB of the block potentially containing data from previous containers. Consequently, raw disk reads could return bytes that the new container had never written. Researchers used ext4 directory block checksums to distinguish their own written blocks from those of other users. In six production deployments, all 5,614 testable directory blocks originated from other users, revealing 2,700 distinct external directory inodes. Across 24 deployment points on four continents and 22 underlying nodes, residual data was found on 18 and 20 nodes respectively. Recovered block types included directory structures, database pages, and intact SQLite databases.

Cloudflare clarified specific limitations of the vulnerability. Attackers could not select victims, workloads, or hosts, nor could they read connected disks or guarantee the presence of residual data. Data exposure depended on where Cloudflare deployed workloads and which freed blocks dm-thin reallocated. Researchers did not demonstrate how to tamper with other customers' data or show any impact on availability. Security professionals on LinkedIn focused on where isolation mechanisms failed rather than the platform itself. Peter Ward, a senior cloud security engineer at Visa, noted that such issues recur and argued that control planes for ephemeral disks and shared hosts should explicitly enforce zeroing on allocation or wiping on release, rather than relying solely on network isolation. He suggested a testing method where teams verify that every reused volume path is zeroed upon allocation and treat residual data on shared storage as a primary isolation control. Sherin Shahanas, a technology expert in cloud computing and cybersecurity, pointed out that root causes are rarely verified, stating that isolation is often an architectural claim rather than a storage-layer tested feature. He asked teams running shared infrastructure whether they know or merely assume that freed blocks are zeroed before reuse.

The disclosure occurred between two product releases. Microsoft officially launched Azure Container Apps Sandboxes, stating that each workload runs within a hardware-isolated microVM boundary. Google released benchmark results for GKE Pod snapshots, a feature that uses gVisor to checkpoint memory and disk, storing results in Cloud Storage. Both vendors provide isolation solutions for untrusted code execution in agentic workloads. The Cloudflare disclosure highlighted that security scope includes layers beneath those mentioned in announcements, including block allocators. If these reactions are representative, the lesson for practitioners is to focus on verification steps, not just vendor selection. The Firecracker boundary held, but the data leak occurred beneath it, specifically where a performance optimization option skipped zeroing during block reuse.

Cloudflare responded rapidly, though the timeline indicates that a fix alone was insufficient. The report was received at 15:26 UTC on September 4. Cloudflare created an incident ticket at 18:45, merged a runtime fix at 21:27, and merged changes for new and online resource pools at 22:03. Staged deployment began at 23:15 that day and completed on September 7. Removing skip_block_zeroing restored default behavior for newly allocated blocks but did not clean blocks already mapped to existing thin block devices, whether in running container disks or host snapshot caches for OCI image layers. New containers could inherit these mappings instead of reallocating blocks. Therefore, Cloudflare disabled all running container disks, wiped host data during off-peak hours, restarted virtual machines, and cleared image caches on each host. This cleanup finished on September 19. Cloudflare stated that after discovering the issue, it built detection signatures based on a pattern of small writes followed by large reads and applied them to retained historical disk I/O telemetry. Analysis showed that only the researchers and Cloudflare's own engineers performing authorized verification matched this pattern. Researchers confirmed that their proof of concept no longer functioned after the changes took effect. Data recovered under their control was securely deleted after the report was submitted. Cloudflare issued the bounty on September 14.