Cloudflare Containers Had a Cross-Tenant Disk Leak — Here Is What Happened

Cloudflare disclosed a storage misconfiguration in its Containers platform last week that let paying customers read leftover disk data from other customers’ workloads on the same host. The data recovered by a security researcher was not theoretical: complete SQLite databases, .env files, Chromium browser profiles, and directory trees — real artifacts from real workloads — were readable from 18 of 24 test placements across four continents. The flaw is fully fixed and no customer action is required. But the root cause is worth a few minutes of your time, because the assumption it breaks is one most developers hold without thinking about it.

One Disabled Option, Sixty Kilobytes of Someone Else’s Data

Cloudflare Containers assigns each container a writable root disk backed by Linux device mapper thin provisioning — dm-thin. With thin provisioning, physical storage blocks are only allocated when data is actually written, and when a container is deleted, its blocks return to a shared pool. This is efficient and standard. The problem was one configuration option: skip_block_zeroing.

By default, dm-thin zeros a block before handing it to a new workload — it wipes the previous tenant’s bytes. With skip_block_zeroing enabled, it does not. Cloudflare’s pool used 64 KiB blocks. If you write 4 KiB to a freshly allocated block, dm-thin hands you the full 64 KiB. You wrote 4 KiB. The other 60 KiB still belong — in physical content — to whoever had that block last.

Security researcher Oren Yomtov at Accomplish turned this into a proof of concept by writing 4 KiB-aligned blocks into free regions of newly allocated storage, then reading the raw block contents. Across 5,614 testable directory blocks, 2,700 contained distinct foreign directory inodes — entries from other customers’ containers. The recovered artifacts included structurally complete SQLite databases, .env files, credential artifacts, and Chromium browser profiles.

Three Products Were Affected — Including the One Sold for Isolation

The affected surface was broader than just Cloudflare Containers. Cloudflare Sandboxes, which runs on Containers infrastructure, was also affected. Sandboxes is the product Cloudflare sells specifically for executing untrusted code — the isolation layer for AI agent code execution, browser automation, and third-party plugins. The storage gap existed in the product whose primary value proposition is safe isolation.

Cloudflare Browser Rendering (Browser Run) was affected as well. All three products shared the same underlying storage pool configuration.

Timeline: Fast Fix, Responsible Disclosure

Yomtov reported the issue via Cloudflare’s HackerOne program on September 4. Cloudflare re-enabled block zeroing for newly allocated blocks by September 14 and completed a full fleet cleanup — retiring all existing container disks and clearing cached snapshots — by September 19. Public disclosure followed on September 24. Cloudflare’s retained disk I/O telemetry showed the distinctive attack pattern (small 4 KiB writes followed by large reads from new allocations) only from the researcher and authorized Cloudflare engineers. No malicious exploitation was confirmed.

Cloudflare’s official guidance: customers do not need to take any remediation action. The company noted that organizations may want to consider rotating secrets from affected workloads as a precaution based on their own risk policies — but this is an optional judgment call, not a required response to active exploitation.

The Lesson That Travels Beyond Cloudflare

The real takeaway is not about Cloudflare specifically — it is about how cloud isolation actually works. Compute isolation and storage sanitization are separate controls. A container’s compute can be perfectly isolated via microVMs or V8 isolates while its storage is served from a shared pool that is not being cleared between tenants. The two layers do not automatically inherit each other’s guarantees.

This pattern is not new. Researchers have found analogous residual data issues in cache layers, page tables, and memory allocators across cloud providers over the years. The specific vector changes; the underlying pattern — a recycled resource not being sanitized — does not.

If you operate infrastructure using dm-thin pools — in LVM, OpenStack, or a self-managed Kubernetes cluster — check whether skip_block_zeroing is set in your pool configuration. The option exists because zeroing blocks has a performance cost, and operators sometimes disable it for throughput. In single-tenant environments, this is a reasonable trade-off. In shared environments, it is not.

# Check your dm-thin pool configuration
dmsetup status <pool_name>

# Look for the "skip_block_zeroing" feature flag in the output
# If present, verify the pool only serves single-tenant workloads

Cloudflare’s official post-mortem is technically honest about what was recoverable and what was not, and it is worth reading in full if you build anything in multi-tenant environments. The Linux kernel documentation for dm-thin covers the full list of pool options — including skip_block_zeroing and its intended use cases — if you want the complete picture.