The scariest bug in multi-tenant cloud isn’t some complex remote code execution chain.[unverified] It is when the walls between tenants vanish because of a storage configuration flag.[unverified]

Security researchers at Accomplish recently disclosed a cross-tenant data exposure vulnerability in Cloudflare Containers and Sandboxes.[1][3] By exploiting a quirk in how Linux allocates thin-provisioned storage, they could read residual data left behind by other customers on the same physical host.[1][2]

The 64 KiB window

Cloudflare Containers run on multi-tenant infrastructure using Firecracker microVMs.[2] To give each container a writable root disk, Cloudflare relies on Linux device mapper thin provisioning (dm-thin).[2]

Thin provisioning allocates physical storage only when a virtual disk actually writes to an unmapped region.[2] The storage pool handling this was configured with a 64 KiB block size.[2] When a container spun down, its blocks went back into a shared pool serving multiple customers.[2]

The problem was a single configuration option: skip_block_zeroing.[2]

With this flag set, dm-thin skipped clearing newly allocated blocks.[2] If a new container wrote a full 64 KiB block, it replaced the old data completely.[2] But if it wrote less than that, the remainder of the block kept whatever data the previous owner left there.[2]

Oren Yomtov and the Accomplish team figured out that by intentionally writing 4 KiB chunks into unmapped ext4 free space, they could force dm-thin to allocate a 64 KiB block from the shared pool.[2][3] The 4 KiB write would overwrite part of the block, leaving 60 KiB of the previous customer’s data perfectly readable.[2]

Scraping the shared drive

The researchers tested this across 24 placements on four continents. They found residual material on 18 of them, spread across 20 different underlying nodes.[2]

The recovered data was not just fragmented junk.[unverified] They successfully pulled directory structures, database pages, Chromium profiles, .env files, and structurally complete SQLite databases.[1][2][3]

Cloudflare confirmed the bug and noted that an attacker could not target a specific victim or workload.[2] You get whatever blocks the allocator hands you.[unverified] But in a multi-tenant environment running backend services and code execution jobs, random residual data is more than enough to be dangerous.[1]

The cleanup

Cloudflare mitigated the issue by dropping the skip_block_zeroing flag, which restored the default behavior of wiping newly allocated blocks before exposing them.[2]

But that only stopped new leaks.[unverified] Blocks already mapped into running containers or cached in host OCI image layers still held residual data.[2] To fully sanitize the fleet, Cloudflare had to drain hosts off-peak, restart the virtual machines, and clear every host’s image cache so all disks were recreated with zeroed allocations.[2]

Cloudflare’s telemetry review found no evidence of malicious exploitation prior to the Accomplish team’s authorized testing.[2]

The transparency in Cloudflare’s joint write-up with the researchers is the standard we expect from infrastructure providers.[unverified] They broke down the root cause, explained the forensic investigation, and detailed the fleet-wide cleanup.[unverified] Still, it is a sharp reminder that in the cloud, you are always sharing a physical disk with strangers, and one bad flag in a storage driver can bridge that gap.[unverified]

Sources

[1] https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data — Cloudflare fixes Containers cross-tenant flaw exposing customer data [2] https://blog.cloudflare.com/containers-cross-tenant-vulnerability — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers [3] https://accomplish.ai/blog/escaping-the-cloudflare-sandbox — Escaping the Cloudflare sandbox - Accomplish Blog