Every serverless and container platform sells the same implicit promise: your workload runs on shared metal, but the boundaries hold. Cloudflare has just disclosed a case where one of those boundaries didn't — thin-provisioned storage pools configured to skip zeroing reused blocks, with researchers recovering directory structures, database pages and complete SQLite databases belonging to other tenants across four continents. The company has remediated it and says it found no evidence of exploitation.

What strikes me about this is how unglamorous the failure is. There's no exotic speculative-execution side channel, no clever container escape. It's block reuse without scrubbing — a storage hygiene problem that predates cloud computing by decades, re-enacted at a scale where one configuration choice touches tenants on four continents at once.

An old failure mode with a new blast radius

Anyone who has handled disk disposal knows the principle: deleting a file removes the pointer, not the bytes. The same physics applies inside a thin-provisioned pool. Blocks get returned to the pool when a workload ends, then handed to the next tenant. Unless something explicitly zeroes them — or the layer above guarantees it never reads an unwritten block — the next tenant can read whatever the previous one left behind. On a single-tenant SAN, that's an internal data-handling concern. On a multi-tenant edge platform, it's a cross-organisational one.

The detail I'd draw attention to is that SQLite databases came back whole. That's not a curiosity of the research method; it's a consequence of how modern ephemeral compute is used. Short-lived containers and sandboxes routinely write their working state to a local file, because the whole point of the pattern is that the storage is throwaway. Session data, scraped content, intermediate results, cached tokens, embedded databases — things nobody classified, because nobody thought of a container's scratch disk as a data store. It is one. It just happens to be a data store with no retention policy, no backup, and, as it turns out, no guaranteed erasure.

You could not have detected this

This is the part worth sitting with. If you were a tenant on an affected platform, there is no log you own that would have shown your data being read by someone else. No audit trail in your account, no anomalous egress from your workload, no alert in your SIEM. The event happens below your visibility line, in infrastructure you have no telemetry on and no contractual right to instrument.

That's not a criticism unique to Cloudflare — it's structural to every managed platform. But it does mean the usual detect-and-respond reflex has nothing to work with. For this class of risk, your only real controls are the ones you apply before the data touches the platform, and the ones you can verify in the vendor's design rather than in your own telemetry. Detection isn't an option; prevention and contract are.

"No evidence of exploitation" is a statement about telemetry

Vendors say this constantly and it's usually honest, but it's worth reading precisely. It means: in the logs we keep, for the period we keep them, with the detections we had written at the time, we saw nothing. For a bug where the malicious action is a read of a block that the reader is nominally entitled to read, the detection surface is thin to begin with. Absence of evidence here is weaker than it sounds, and I'd treat it as a reason not to panic rather than a reason to close the file.

The practical consequence is that you cannot say, with confidence, that nothing of yours was exposed. You can only reason about what you put there and how bad it would be. That's a data classification exercise, which is why these incidents always end up pointing back at the same unglamorous discipline.

The geography problem nobody budgeted for

Recovery of data across four continents is the line that will interest anyone with a data residency obligation. Edge platforms exist precisely to run your code close to the user, which means your workload's storage lands wherever the request landed. If blocks are reused within a regional pool, the exposure stays regional; the reported spread suggests the research was simply conducted broadly. Either way, residency commitments on an edge platform are a property of the vendor's scheduling and storage design, not something you can assert from your side.

If you have made residency claims in a privacy notice or a DPA on the strength of a platform's marketing, this is a prompt to go and read the actual technical documentation on where ephemeral storage lives. [AUTHOR: add a real example from your own work here, if you have one, on residency claims versus platform behaviour.]

What to actually change

Nothing here calls for ripping out your edge platform. The fix is in, and the alternative providers run the same general architecture with the same general risks. What it should change is the set of assumptions you let through unchallenged.

  • Treat ephemeral storage as a classified data store. If it holds anything you'd care about in a breach report, it needs the same classification as a database.
  • Encrypt above the platform. Application-layer or per-tenant encryption with keys held outside the compute environment turns a block-reuse leak into a recovery of ciphertext.
  • Keep secrets out of the filesystem. Tokens and credentials written to a container's scratch disk inherit every weakness of that disk; inject them at runtime and keep them in memory.
  • Ask the vendor the storage question directly. Is reused block storage zeroed, or is the guarantee provided some other way? Get the answer in writing, not from a trust-centre page.
  • Record the residency answer for ephemeral storage specifically — separately from your answer for durable storage, because they are frequently not the same.

Credit where it's due, and the standard it sets

A vendor that finds a cross-tenant exposure, fixes it, and publishes a technical explanation of the root cause is doing the thing we keep asking the industry to do. The far more common outcome is a quiet patch and a line in a changelog. When you next run a supplier review, the useful question isn't whether a provider has had a serious bug — they all have — but whether you learned about it from them, in enough detail to assess your own exposure. That's a procurement criterion, and it ought to carry more weight than another certification badge.

Source: Cloudflare Fixes Cross-Tenant Data Exposure in Containers