Date: September 27, 2026
Author: Threat Research & Intelligence Team, Digital Spying
Category: Cloud Security / Multi-Tenancy Isolation / Storage Forensics
Tags: Cloudflare, Containers, Multi-Tenancy, dm-thin, Data Leak, Linux Kernel, Cloud Security
Executive Summary
The foundational promise of modern cloud computing rests upon strict tenant isolation: no customer workload should ever observe the memory, CPU state, or storage remnants of another. On September 27, 2026, BleepingComputer and Cloudflare published comprehensive post-mortem analyses detailing a critical cross-tenant data exposure vulnerability in Cloudflare Containers and Sandboxes—the edge execution platform enabling developers to run arbitrary containerized microVMs across Cloudflare's global infrastructure.
Uncovered by independent security researcher Oren Yomtov of Accomplish, the vulnerability resided in the underlying Linux storage virtualization subsystem—specifically, the Linux Device Mapper Thin Provisioning layer (dm-thin). When a customer's ephemeral container terminated and its root disk volume was reclaimed, the physical storage blocks were returned to a shared node pool without being sanitized.
By executing a micro-write of just 4 KiB into an unallocated disk sector, a newly spawned container could force dm-thin to allocate a recycled 64 KiB physical block from the shared pool. Because zero-initialization was inadvertently disabled, the remaining 60 KiB of the block retained raw, readable remnants from prior workloads. During systematic testing across Cloudflare's infrastructure, researchers successfully recovered residual material across 20 out of 22 underlying server nodes (91%) and 18 out of 24 container placements, exposing directory layouts, filesystem metadata, database pages, and structurally complete SQLite databases from other tenants.
Technical Deep-Dive: Deconstructing the dm-thin Storage Leak
To understand how multi-tenant isolation collapsed at the block layer, we must examine the internal mechanics of Linux Device Mapper Thin Provisioning, page cache boundaries, and block reallocation routines.+-----------------------------------------------------------------------------------+
| CLOUDFLARE CONTAINERS CROSS-TENANT DATA LEAK FLOW |
|---|
Tenant A (Victim Workload) Host Kernel (dm-thin Pool) Tenant B (Attacker / Probe)
| | |
| 1. Tenant A runs SQLite database, API tokens, | |
| and web server in container sandbox | |
|------------------------------------------------->| |
| | |
| 2. Tenant A workload finishes execution; | |
| Container root volume destroyed | |
|------------------------------------------------->| |
| | |
| | 3. Physical Storage Blocks returned to pool: |
| | [ Block #4092: 64 KiB contains Tenant A ] |
| | - [SECURITY FLAW] Block Zeroing SKIPPED! |
| | - Block remains dirty in pool |
| | |
| | 4. Tenant B spins up fresh container sandbox |
| |<---------------------------------------------|
| | |
| | 5. Tenant B writes small 4 KiB chunk |
| | to unallocated virtual disk sector |
| |<---------------------------------------------|
| | |
| | 6. dm-thin assigns recycled Block #4092: |
| | - Overwrites first 4 KiB with Tenant B's |
| | - Leaves remaining 60 KiB UNTOUCHED! |
| | |
| | 7. Tenant B reads raw 64 KiB block: |
| | - Bytes 0-4096: Tenant B data |
| | - Bytes 4097-65536: TENANT A RESIDUAL! |
| |--------------------------------------------->|
| |
| 8. Recovered Sensitive Data: |
| - SQLite database files |
| - API keys & environment |
| - Directory structures |
|<================================================================================================|
1. The Architecture of Cloudflare Containers
Cloudflare Containers allows developers to deploy full-stack workloads, containerized agents, and headless browser tasks directly to Cloudflare's edge. Behind the scenes:
* Containers run inside lightweight virtualized sandboxes.
* Each container is provisioned with an ephemeral, copy-on-write root filesystem backed by a virtual block device.
* To minimize storage footprint and provisioning latency, the host operating system utilizes Linux Device Mapper Thin Provisioning (dm-thin).
2. The Root Cause: Disabled Block Zeroing in dm-thin
In thin provisioning, storage is not allocated upfront. Instead, virtual blocks are mapped to physical storage pool blocks on demand as write requests occur:
* dm-thin operates with a default block allocation chunk size (typically 64 KiB).
* Standard security configurations mandate that when a previously used block is reassigned, the kernel must explicitly write zeroes across the entire block (zero_new_blocks = 1) before returning the block to user-space.
* During optimization passes intended to accelerate microVM spin-up times, Cloudflare had enabled a configuration setting that bypassed automatic zero-initialization of reassigned blocks.
* Consequently, when a physical 64 KiB block was returned to the thin pool following the destruction of Tenant A's container, its raw magnetic/flash memory bits remained completely intact.
3. Exploitation Mechanics: Reconstructing Residual Filesystems
When Tenant B spawned a new container and initiated a write operation:
1. The Trigger Write: Tenant B wrote 4 KiB (a single memory page) into an offset on its virtual disk.
2. Chunk Allocation: dm-thin allocated an existing, dirty 64 KiB physical block from the thin pool to fulfill the virtual block mapping.
3. The Data Exposure Window: The kernel overwrote only the specific 4 KiB offset modified by Tenant B. The remaining 60 KiB of the physical chunk remained untouched.
4. Data Siphoning: Tenant B then executed sequential raw block reads across the allocated virtual device using standard POSIX system calls (read()).
5. Findings: Across 22 server nodes examined in the wild, researchers detected residual data on 20 nodes (90.9%). Among the recovered artifacts were:
* Directory entry structures (dentry) revealing internal file paths and application architectures.
* Filesystem inodes and metadata headers.
* Unencrypted SQLite database pages containing session tokens, application logs, and relational tables.
Global Impact: The Perils of Multi-Tenant Edge MicroVMs
While Cloudflare verified through extensive telemetry audits that no malicious exploitation occurred prior to remediation, the incident exposes severe systemic risks facing the modern cloud edge:
* The Rise of Ephemeral MicroVMs: Cloud providers are transitioning from persistent virtual machines to millisecond-lifecycle microVMs (such as Firecracker and Cloudflare Containers). High churn rates in ephemeral disks multiply the frequency of block reallocations exponentially.
* Shared Physical Host Footprint: Unlike dedicated cloud instances, edge workers and serverless containers from thousands of distinct enterprises co-exist on the same bare-metal host, making multi-tenancy flaws immediately impactful.
* Failure of Defense-in-Depth: In container security, isolation traditionally focuses on cgroups, namespaces, and seccomp profiles. This incident underscores that the storage stack remains a prime isolation vulnerability.
Remediation & Hardening Blueprint for Cloud & Infrastructure Architects
Cloudflare resolved the issue across its global edge by September 19, 2026, without requiring customer downtime. For infrastructure engineers and multi-tenant platform architects, the incident serves as an essential case study in defensive storage engineering:
1. Enforce Mandatory Block Zeroing in Storage Virtualization
Never disable block zeroing on multi-tenant thin pools. Verify that zero_new_blocks is strictly active in dm-thin:# Verify dm-thin pool status and zeroing configuration
dmsetup status /dev/mapper/thin-pool
dmsetup message /dev/mapper/thin-pool 0 set_transaction_id
Ensure thin pool metadata explicitly mandates zeroing:lvchange --zero y /dev/vg_name/thin_pool_name
2. Implement Tenant-Isolated Cryptographic Disk Erasure
Rather than relying solely on kernel-level zeroing:
* Per-Tenant Ephemeral LUKS Encryption: Format each ephemeral container disk with its own unique LUKS encryption key generated in-memory.
* Instant Cryptographic Shredding: Upon container termination, immediately purge the in-memory encryption key. Even if unzeroed raw blocks are subsequently reassigned to another tenant, the residual bytes represent cryptographically indecipherable ciphertext.
3. Deploy Automated Storage Remanence Verification
Implement automated testing routines within your CI/CD pipeline to verify tenant boundaries:# Conceptual verification script for container storage sanitization
import os
BLOCK_DEVICE = "/dev/mapper/container_root"
SAMPLE_SIZE = 64 * 1024 # 64 KiB block
def test_storage_sanitization():
with open(BLOCK_DEVICE, "rb") as disk:
data = disk.read(SAMPLE_SIZE)
Verify that unwritten blocks contain only null bytes (0x00)
assert data == b"\x00" * SAMPLE_SIZE, "CRITICAL: Non-zero bytes detected in fresh block!"
For cloud architecture threat analysis, kernel security advisories, and container isolation research, explore Digital Spying.