As reported by BleepingComputer, Cloudflare has remediated a cross-tenant data disclosure vulnerability in its Containers and Sandboxes services that could have allowed any customer on the Workers Paid plan to recover fragments of other customers' filesystem data — including .env files, SQLite databases, Chromium profiles, and credential files — from previously allocated storage blocks on the same physical host.

Cloud Security Alert: The vulnerability is a textbook example of how performance optimizations in shared infrastructure can silently undermine tenant isolation.

What Actually Broke

The vulnerability is a textbook example of how performance optimizations in shared infrastructure can silently undermine tenant isolation. Cloudflare's container backing store used thin volumes provisioned from a shared pool. When a container's root disk was deleted, its 64 KiB physical blocks were returned to that pool — but the system was configured to skip zeroing those blocks before reuse. This is a common storage optimization: zeroing blocks adds latency and I/O overhead. The trade-off is usually acceptable because new allocations overwrite old data. But the researchers exploited a mismatch: by writing just 4 KiB into a fresh 64 KiB block, they triggered allocation of a recycled physical block that still contained 60 KiB of a previous tenant's data.

This is the same class of vulnerability that has bitten other cloud and virtualization providers over the years — the pattern where logical deletion doesn't equate to physical sanitization, and where an attacker can coerce the system into exposing the gap. What makes this particularly dangerous in a container context is the density of sensitive artifacts that accumulate on a container's root filesystem: secrets in .env files, application databases, session tokens, and browser-stored credentials.

Scale and Impact

The researchers found residual data on 18 of 24 container placements across 20 of 22 nodes tested — a roughly 75% and 91% hit rate respectively. That's not a theoretical edge case; that's a near-deterministic outcome on affected infrastructure. While Cloudflare states the researcher used aggregate-counting scripts rather than exfiltrating actual customer data, the practical reality is that any adversarial Workers Paid customer who understood the storage layout could have harvested sensitive material from co-located tenants.

Importantly, this was not a hypervisor escape or a container runtime exploit. The attacker couldn't read an active container's disk, couldn't modify another customer's data, and couldn't disrupt workloads. The exposure window was limited to the gap between when a container's disk was deleted and when its physical blocks were overwritten by a new tenant. But in a high-churn environment where containers spin up and down continuously, that window is perpetually open.

Why This Matters Beyond Cloudflare

Every multi-tenant cloud provider that reuses storage blocks without cryptographic erasure or per-tenant encryption keys faces this exact risk. The lesson isn't specific to Cloudflare — it's that any platform offering ephemeral compute on shared infrastructure must treat block zeroing or per-tenant key isolation as non-negotiable, not as a tunable performance optimization. The cost of a single cross-tenant disclosure — particularly one involving credential files and databases — vastly outweighs the I/O savings from skipping a zero pass.

Cloudflare's remediation appears thorough: they removed the skip-zeroing configuration, retired existing container disks, and cleared cached snapshots that might retain old block states. Their disclosure transparency is commendable, and the HackerOne-mediated responsible disclosure process worked as intended.

Shield53 Recommendations

Shield53 Recommendations
For Cloudflare Containers customers: No active exploitation has been reported, but treat this as a credential exposure event. Rotate any secrets that may have been stored in container .env files, SQLite databases, or Chromium profiles during the exposure window (approximately September 4 through remediation). Audit your container image build process to ensure secrets are injected at runtime via environment variables or secret managers — not baked into the filesystem.
For any multi-tenant platform operator: Review your storage allocation and deletion path. Confirm that physical blocks are either zeroed on deallocation, encrypted with per-tenant keys that are destroyed on deletion, or both. Document this as a security control, not a performance decision.
For defenders assessing cloud container platforms: Add these questions to your vendor risk assessment: (1) How are deleted volumes sanitized at the physical layer? (2) Are per-tenant encryption keys used for storage isolation? (3) What is the block allocation granularity versus the zeroing granularity? The 64 KiB vs. 4 KiB mismatch here is the exact type of configuration detail that creates exploitable gaps.
Broader hygiene: Assume that any data written to a shared infrastructure filesystem may persist beyond your control of that resource. Apply least-privilege to what you place on container root disks, and treat container filesystems as ephemeral — not as a secure storage location for long-lived credentials.
Bottom line: Cloudflare caught and fixed this responsibly, and the researcher's disclosure was exemplary. But the vulnerability pattern — shared physical storage blocks not being sanitized between tenants — will continue to surface across the industry until the default shifts from "overwrite is sufficient" to "cryptographic erasure or per-tenant key isolation is mandatory."