Tech Infrastructure

Tech Infrastructure: Cloudflare Cross-Tenant Disk Leak

Published September 25, 2026 · DNS Benchmark Pro Editorial · Reading time: 6 minutes

The most instructive piece of tech infrastructure news this week is not a zero-day vulnerability in a perimeter appliance. It is a single configuration flag. Cloudflare's disclosure describes how one Linux storage option, left enabled on pools shared across customer accounts, let a container recover kilobytes of a stranger's deleted filesystem — directory trees, database pages, and in some cases structurally complete SQLite files. Nothing was exploited. That is largely luck, and the mechanics are worth understanding for anyone who runs workloads on shared server infrastructure.

What Cloudflare disclosed on 24 September

Cloudflare Containers give each workload a writable root disk inside a Firecracker microVM, exposed to the guest as /dev/vdc. Those disks are not preallocated. They are carved out of a host-level pool using the Linux device mapper's thin provisioning target, dm-thin, which hands out physical storage lazily in 64 KiB blocks as the guest touches new regions.

By default, dm-thin zeroes a block before exposing it to a new consumer. Cloudflare had skip_block_zeroing enabled — a performance option that removes that write. On a pool dedicated to one tenant, skipping the zero pass is a reasonable trade. On a pool shared between accounts, it means a recycled block arrives at its next owner still carrying the previous owner's bytes.

Inside dm-thin: a 4 KiB write that reads 60 KiB

The proof of concept is elegant precisely because it needs no memory corruption, no privilege escalation and no exploit primitive at all. The researcher mapped the 64 KiB-aligned free-space regions of the guest's ext4 filesystem, wrote exactly one aligned 4 KiB page into each of them, and then read the raw block device back.

Each of those small writes forced dm-thin to allocate a fresh 64 KiB physical block from the shared pool. Because zeroing was skipped and only 4 KiB was actually overwritten, the remaining 60 KiB was whatever the previous tenant had left there. Reading /dev/vdc directly bypassed the filesystem's own view of what was allocated.

The validation numbers are what make this more than a theoretical finding. Across six production placements the researchers examined 5,614 testable directory blocks and identified 2,700 distinct foreign directory inodes, verified against ext4 checksums with no false positives. Residual data turned up on 18 of 24 placements and on 20 of 22 underlying nodes across four continents. Recovered material included Chromium profiles, .env files and credential material — the ordinary contents of a build sandbox, which is exactly the problem.

The response timeline

Under six hours from report to merged fix is a strong showing for a platform of this size, and the remediation went beyond the flag: Cloudflare removed skip_block_zeroing fleet-wide, retired every container disk created before the fix, drained hosts during off-peak windows and cleared cached image snapshots so no host could inherit an old mapping. A review of retained disk-I/O telemetry, using the researcher's activity as a detection signature, surfaced only authorised testing.

Why this is a cloud security problem, not a container bug

Multi-tenant isolation is usually discussed at the CPU and memory boundary — hypervisor escapes, side channels, speculative execution. Storage reuse gets far less attention because it looks like an operational detail rather than a security boundary. This incident shows it is both.

Three properties limited the damage, and none of them are controls. An attacker could not choose a victim, could not reach a disk that was still attached, and depended entirely on Cloudflare's own placement decisions for what landed on their host. That is a probabilistic defence, not a deterministic one. For regulated workloads it would not survive an audit question, and it is the reason the operative IT security lesson here is about defaults: any performance flag that removes a scrubbing step needs a written justification tied to the tenancy model of the pool it runs on.

What it means for DNS security and encrypted transports

Cloudflare was explicit that the exposure was confined to Containers and Sandboxes. The CDN, authoritative DNS and the 1.1.1.1 resolver run on different infrastructure and were not implicated, so there is no DNS security action to take from this advisory in itself.

The architectural point still lands. A growing share of enterprise resolution is brokered by the same edge platforms that host compute: DNS over HTTPS endpoints, DoT listeners and split-horizon policy increasingly terminate at a provider rather than on a resolver you own. When resolution, TLS termination and untrusted tenant compute share a vendor, a failure in any one of them becomes a question about all three. Credentials recovered from a build sandbox are perfectly capable of being used to change a zone.

The practical control is independent measurement. A network diagnostic tool that measures real DNS-over-HTTPS resolution latency tells you what your resolvers are actually doing from your vantage point rather than what a status page says, and our explainer on DNS over HTTPS covers where that latency accumulates. For the perimeter-appliance side of the same week, see our report on the F5 BIG-IP APM zero-day.

The checklist for shared-tenancy platforms

1. Treat sandbox secrets as disclosed by default. Anything written to an ephemeral container disk — .env files, cached tokens, CI credentials — should be short-lived and rotated on a schedule that does not depend on a vendor post-mortem.
2. Audit your own thin-provisioned pools. If you run dm-thin, LVM thin pools or overlay storage across tenants or trust zones, check whether zeroing is disabled and whether the pool is genuinely single-tenant.
3. Encrypt at rest inside the guest. Block residue is unreadable if the previous tenant's filesystem was encrypted with a key that died with the workload.
4. Keep an off-platform baseline. DNS server performance and network latency figures gathered from outside your provider are what let you reason about an incident independently.
5. Read the placement model, not just the SLA. Ask which pools are shared, at what granularity, and what is zeroed between tenants.

Industry impact

Two things deserve credit here, and one deserves scrutiny. Cloudflare's disclosure is detailed enough to be reproducible, names the mechanism rather than hiding behind "a configuration issue", and publishes a timeline down to the minute — a standard the rest of the industry should be held to. The bug bounty channel worked exactly as designed.

The scrutiny belongs to the class of defect. Serverless containers and AI code sandboxes are the fastest-growing layer of tech infrastructure, and they are built on storage primitives designed for a single-tenant world where skipping a zero pass was free. Every provider running untrusted code on pooled block storage has some version of this decision in its configuration, and most have never had a researcher look. The questions worth asking your own platform team this week are narrow and answerable: which pools are shared, what is zeroed between tenants, and who checked last.

Sources

• Cloudflare Blog — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers
• The Hacker News — Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data
• Cybersecurity News — Cloudflare Containers Vulnerability Could Leak Data Between Customer Workloads
• GBHackers — Cloudflare Containers Flaw Could Expose Data From Other Customers' Workloads
• Linux kernel documentation — Device Mapper thin provisioning

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Cloudflare office photographs are by Wikimedia Commons contributor HaeB, licensed CC BY-SA 4.0; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated.