When Shared Blocks Remember Too Much: Cloudflare’s Cross-Tenant Leak Warning
A remediated storage flaw in Cloudflare’s Containers stack shows how multi-tenant isolation can fail at the disk layer, even when compute boundaries stay intact.
Introduction
Cloud security usually gets judged at the VM boundary, but this case turns attention to a quieter layer: reused storage blocks. A remediated vulnerability in Cloudflare’s Containers platform could have let one customer’s workload recover residual disk data left behind on the same physical host. Cloudflare said the same underlying disk implementation also affected Sandboxes and Browser Run.
At a technical level, the lesson is blunt. A strong isolation story can still leak if the storage substrate is shared and not fully scrubbed before reuse.
Fast Facts
- The issue involved cross-tenant recovery of residual disk data on shared hosts.
- Cloudflare said Containers used thin-provisioned storage blocks that were not zeroed before reuse in the affected path.
- Sandboxes and Browser Run used the same Containers disk implementation and were therefore in scope.
- The technique could not target a specific victim or host, which limited precision but not the underlying exposure risk.
- Public information does not confirm successful exfiltration of customer data.
Body
The interesting part of this case is what it is not. It is not a classic code-execution bug, and it is not evidence that the virtual machine boundary failed. The weakness sits below that line, in the way thin-provisioned storage can recycle blocks across tenants. If a new workload writes only part of a reused block, stale bytes may remain readable in the unwritten portion unless the system explicitly clears them first.
That makes storage remanence a real cloud risk. Depending on what was left behind, residual bytes can include filesystem metadata, application fragments, or other sensitive material. In a multi-tenant environment, that is enough to turn a performance optimization into a confidentiality problem.
Cloudflare’s architecture matters here because multiple products shared the same backend behavior. If one disk layer is common to Containers, Sandboxes, and Browser Run, then a flaw in that layer can ripple outward even when the user-facing products look very different. From a defensive perspective, this is a reminder that tenancy boundaries are only as strong as the lowest shared layer in the stack.
The practical controls are equally clear: zero reused blocks before reassignment, retire stale disks and cached snapshots carefully, and keep secrets out of disposable filesystems whenever possible. For operators of sandboxed or containerized services, the trust boundary must include storage sanitation, not just network policy and process isolation.
At the time of writing, public information supports a cross-tenant residual-data exposure risk, but it does not establish the full impact or any confirmed downstream compromise. That distinction matters. Security teams should treat the event as a warning about shared storage design, not as proof that every isolated workload is equally at risk.
Conclusion
The broader lesson is simple: cloud isolation is only as durable as the housekeeping beneath it. When shared infrastructure reuses disk blocks, sanitization becomes part of the security boundary, not a cleanup task. In modern multi-tenant systems, the hidden danger is often not what runs in the sandbox, but what the sandbox inherits from the last tenant.
TECHCROOK
hardware-encrypted external drive: For sensitive files that should not live on shared or disposable systems, a hardware-encrypted external drive offers local control and simple offline storage. It is not a fix for cloud isolation bugs, but it can help keep important copies under direct custody when handling logs, exports, or backups.
WIKICROOK
- Multi-tenancy: A model where multiple customers share the same physical infrastructure while keeping logical separation.
- Thin provisioning: A storage method that allocates disk space on demand instead of reserving it all upfront.
- Storage remanence: Leftover data that can remain on reused storage media after a previous workload is gone.
- Firecracker: A lightweight VMM used to run isolated workloads with small virtual machines.
- Block zeroing: Clearing a storage block before reuse so old data cannot be read by a new tenant.



