Stackmaven
Beat report Published 16d ago ·

Cloudflare fixes a cross-tenant disk leak in Containers, and it is a reminder that ephemeral is not private

A vulnerability in Cloudflare Containers let one paying customer recover leftover disk data, including .env files and credentials, from another tenant's earlier workload. No customer action was needed, but it reframes what an ephemeral disk keeps private.

By Stackmaven

Cloudflare has disclosed and fixed a vulnerability in its Containers platform that let one paying customer recover leftover disk data from another tenant’s earlier workload, and the detail worth keeping is what came back: .env files, credential artifacts, and database pages belonging to strangers on the same hardware. The flaw was reported through Cloudflare’s bug bounty program on September 4 and fully remediated by September 19, and it required no customer action to close. What it does not close is a common assumption on serverless-style platforms, that a container’s disk is yours and yours alone.

How the leak worked

The root cause sits in how Cloudflare provisioned container storage. Its hosts used Linux device-mapper thin provisioning, which hands out disk space in fixed 64 KiB blocks from a shared pool, with an option called skip_block_zeroing turned on. As the name suggests, that setting skips wiping a block before reassigning it to the next container. When a workload was deleted, its blocks returned to the pool still carrying the previous tenant’s bytes.

Oren Yomtov, a researcher at the security firm Accomplish, showed how that becomes a leak. By writing a small amount of data into a freshly allocated block and then reading the whole block at the raw disk level, an attacker could recover the roughly 60 KiB of residual data the short write did not overwrite. The technique needed only a Workers Paid account, no exotic access. For a working developer, the plain version is this: deleting a container did not guarantee its disk contents were gone before someone else got the same physical space.

What could be recovered, and what limited the damage

The recovered material was exactly the kind that hurts. Cloudflare and independent reporting describe directory listings, SQLite database pages (some structurally intact), Chromium browser profiles, .env files, and credential files pulled from other customers’ workloads. In production testing, researchers reported leftover material on 18 of 24 attempts, with hits across four continents, so this was not a narrow edge case.

Two constraints kept it from being worse. Cloudflare’s automatic workload placement meant an attacker could not choose a victim, a host, or a specific workload to target, and the technique could not read a disk that was actively attached to a running container. The exposure was residual and effectively random rather than aimed. Cloudflare also found no evidence of malicious exploitation in its telemetry, with only authorized testing matching the pattern. Notably, the same weakness reached Cloudflare Sandboxes, which are built on Containers, so the blast radius covered more than one product name.

Why it matters even with no action required

The remediation was thorough and invisible to customers: Cloudflare removed the skip_block_zeroing option fleet-wide, retired all running container disks, and cleared cached image snapshots. Because the platform fixed it in place, there is no patch for a developer to apply and no configuration to change.

The durable takeaway is about trust boundaries, not remediation steps. Multi-tenant compute sells the idea that isolation is total, and a residual-data flaw is a reminder that isolation guarantees extend only as far as the layer that enforces them, in this case a storage setting chosen for performance. The practical adjustment for developers is modest but real: treat an ephemeral container’s local disk as scratch space that a platform bug could expose, keep long-lived secrets in a managed secret store rather than written to container disk, and rotate anything a workload wrote locally if a platform ever reports this class of issue. The residual-data risk is the platform’s to prevent, but the data you choose to leave on that disk is yours.

What to watch

The encouraging signal here is process working as designed: an external researcher, a bug bounty channel, mitigation within hours, and a full public write-up with a timeline. The class of bug is the thing to keep an eye on, because residual-data exposure follows any system that recycles storage or memory across tenants for speed. As more platforms lean on fast, reused sandboxes to run untrusted and agent-generated code, the question of what the previous occupant left behind is one worth asking of every provider, not just the one that answered it this month.

Sources cited
  1. How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (Cloudflare Blog) blog.cloudflare.com
  2. Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data (The Hacker News) thehackernews.com
  3. Cloudflare Containers Vulnerability Could Leak Data Between Customer Workloads (Cyber Security News) cybersecuritynews.com
esc