Cloudflare Containers bug let you read a neighbor's disk

Shared infrastructure means somebody else's deleted bytes were on your disk first. Cloudflare has now published the case where that stopped being theoretical: a Cloudflare Containers cross-tenant storage flaw let one customer read residual data left behind by another customer's container, including complete database files. It is fixed. The reason it happened is worth an hour of your time.

What actually happened

Per Cloudflare's own write-up, Oren Yomtov of Accomplish reported the issue through HackerOne on September 4, 2026. Cloudflare removed the offending setting that same day, retired every pre-mitigation container disk and cached image snapshot by September 19, and paid the bounty on September 14. No customer action was required.

The root cause is a single Linux storage option. Container root disks were thin volumes on shared dm-thin pools configured with skip_block_zeroing. When a container's volume was deleted, its 64 KiB physical blocks went back into a pool serving multiple customer accounts — without being zeroed. A new tenant who wrote only 4 KiB into a freshly allocated block replaced just that portion; the remaining up to 60 KiB still held whatever the previous owner had written there.

The researchers did not find a theoretical read. Cloudflare reports residual data on 18 of 24 test placements, across 20 of 22 underlying nodes, spread over four continents — and recovered directory structures, raw database pages, and entire SQLite databases. Cloudflare reviewed historical disk-I/O telemetry and found only the researchers' and its own engineers' authorized activity: no evidence anyone else exploited it.

Why multi-tenant residue matters for your business

A full-block write is not the same as a small write. That is the whole bug, and it generalizes. Any layer that recycles storage — container disks, object stores, database pages, a pooled buffer in your own code — leaks the difference between the block size and what you actually wrote. If you allocate and reuse, zero on release or zero on allocate. Pick one and be explicit.

Encrypt application data yourself, above the platform. Everything the researchers recovered was readable because it was at rest in plaintext inside the container. Platform-level disk encryption does not help here — the platform happily decrypted the block for its new owner. If you put SQLite, a cache, or credential material on a container's local disk, encrypt it in your process with a key the container fetches at boot, and the residue is noise.

Container-local disk is scratch space, not storage. We build on Cloudflare, and our rule does not change because of this post: nothing that matters lives on an ephemeral filesystem. State goes to D1, R2, Durable Objects, or Postgres. Treat the local disk as a place to unzip things, and this class of bug never touches your data.

Read the post-mortem, then check your own pools. If you run your own Kubernetes with dm-thin, LVM thin pools, or any storage class with zeroing disabled for performance, go look right now. Cloudflare had the telemetry to prove nobody abused it. Most self-hosted setups do not keep disk-I/O history long enough to answer that question at all.

Sources: Cloudflare Blog, Cybersecurity News.