Cloudflare Fixes Containers Cross-Tenant Flaw Exposing Customer Data

Shared Disk Pool Leaked Data Between Customers

Cloudflare has fixed a vulnerability in Containers and Sandboxes that allowed customers on a Workers Paid account to recover residual data left behind by other customers' containers running on the same physical host. The flaw crossed a fundamental tenant-isolation boundary in Cloudflare's multi-tenant infrastructure, potentially exposing filesystem metadata, directory structures, database pages, and application data — including directory listings, SQLite databases, and files such as .env configuration and credential files.

Cloudflare disclosed the issue in a blog post published September 24, 2026, detailing the technical root cause, the discovery timeline, and the remediation it completed fleet-wide by September 19, 2026. The company says it found no evidence that customer data was compromised by anyone other than the researcher who reported it.

Incident Details

How It Worked

Thin Provisioning Without Block Zeroing

Cloudflare Containers use Linux device mapper thin provisioning (dm-thin) to back the writable root disks assigned to customer containers. Thin provisioning lets Cloudflare allocate physical disk blocks from a shared storage pool on demand, rather than reserving a fixed amount of space per container up front. When a container is deleted, the physical blocks it used are returned to that shared pool so they can be handed out to the next container — potentially belonging to a completely different customer.

Normally, dm-thin zeroes out newly allocated blocks before handing them to a new consumer, ensuring no old data survives the handoff. On Cloudflare's fleet, however, the pool was configured with skip_block_zeroing enabled — a setting that skips this cleanup step, presumably for a performance benefit, and leaves reused blocks containing whatever data the previous tenant had written.

Exploiting a Partial Write

Blocks in the shared pool were allocated in 64 KiB units, but a container's guest filesystem (ext4) could write in much smaller 4 KiB increments. The researcher's proof of concept identified 64 KiB-aligned regions of free space on a new container's disk and wrote a single 4 KiB block into each one. That write forced dm-thin to allocate a full 64 KiB physical block from the shared pool — but only 4 KiB of it was actually overwritten with the attacker's data.

Because block zeroing was disabled, the remaining 60 KiB of that block could still contain whatever a previous, unrelated customer's container had stored there, fully readable by reading back the file.

Real-World Scope

Cloudflare's automatic workload placement meant an attacker had no control over which host, victim, or specific data they might land on — this wasn't a targeted attack technique, and there was no way to read another customer's actively attached disk. Still, in controlled testing, researchers recovered residual material on 18 of 24 container placements, spanning 20 of 22 underlying nodes across four continents — indicating the underlying weakness was widespread rather than an isolated misconfiguration. The same disk implementation also underpins Cloudflare Sandboxes and the Browser Run service within Browser Rendering, both of which were affected.

Impact Assessment

Cloudflare's Response

Cloudflare moved quickly once the report landed on September 4. Within roughly three hours the issue was confirmed in production, and a runtime fix removing skip_block_zeroing from the dm-thin pool configuration was merged the same day, restoring the default behavior of clearing newly allocated blocks before exposing them to a container. The fix rolled out fleet-wide by September 7.

Because containers created before the fix could still be running on disks holding pre-existing residual data, Cloudflare went further:

• Retired all running container disks created prior to the mitigation
• Removed cached OCI image snapshots that predated the fix
• Drained hosts during off-peak hours and restarted affected virtual machines
• Cleared image caches fleet-wide so disks were recreated with properly zeroed allocations

That broader cleanup — which required no customer-side configuration changes — finished on September 19. Cloudflare said the researchers confirmed that any data they recovered during testing was kept confidential and securely deleted after submission, consistent with the company's HackerOne disclosure process, and that it saw "no evidence that this specific attack vector was exploited by anyone else."

Why This Matters for Multi-Tenant Cloud Customers

This incident is a reminder that the isolation boundary in shared cloud infrastructure isn't just about compute and memory — storage reuse at the block level is an equally sensitive attack surface. Thin-provisioned, pooled storage is common across cloud and container platforms precisely because it's efficient; a single disabled safety setting was enough to turn that efficiency into a cross-tenant data leak. For organizations running workloads on any shared container or serverless platform, the incident underscores why data that touches shared infrastructure — even "ephemeral" container disks — should be treated as potentially recoverable by other tenants unless a provider can demonstrate otherwise.

For Security Teams Using Cloudflare Containers or Sandboxes

• No customer action is required — Cloudflare's fix applies fleet-wide automatically
• Review what sensitive data touched container disks before September 19, 2026 (credentials, .env files, database contents) and consider rotating any long-lived secrets that were present in container filesystems during that window
• Avoid writing long-lived secrets to container-local disk generally; prefer secrets managers or environment injection at runtime so residual-disk risk is minimized regardless of the underlying storage implementation

For Cloud and Platform Teams More Broadly

• Audit thin-provisioning and storage-reuse settings on any shared block storage backing multi-tenant workloads — confirm zeroing-on-allocation is enabled by default
• Treat storage-layer isolation as part of the tenant security boundary, not just network and compute isolation
• Support responsible disclosure programs — this issue was caught and fixed within about two weeks of a HackerOne report, well before public disclosure

Key Takeaways

1. Cloudflare Containers and Sandboxes had a cross-tenant data exposure flaw rooted in a shared dm-thin storage pool that skipped zeroing reused 64 KiB disk blocks.
2. Any Workers Paid customer could potentially exploit it by writing small 4 KiB blocks into free space and reading back the leftover 60 KiB of a reused block.
3. The flaw was reported via HackerOne on September 4, 2026 by researcher Oren Yomtov of Accomplish, and Cloudflare merged a runtime fix the same day.
4. Fleet-wide remediation — including disk retirement and cache clearing — completed September 19, 2026, with no customer action required.
5. Cloudflare found no evidence of exploitation beyond the reporting researcher's controlled testing, and no CVE has been publicly assigned.
6. The incident highlights storage-layer isolation as a distinct risk category in multi-tenant cloud and container platforms, separate from compute and network isolation.

Sources

• BleepingComputer — Cloudflare fixes Containers cross-tenant flaw exposing customer data
• Cloudflare — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers
• TechNadu — Cloudflare Patches Cross-Tenant Containers Vulnerability

Related Reading

• Cloudflare BGP Routing Error Cascades Across AWS, X, and More
• Cloudflare 2026 Threat Report: 230 Billion Daily Threats