You're running a multi-tenant container platform. You've implemented network isolation, credential separation, and access controls. But did you check whether your storage backend zeros blocks before reallocation?
A vulnerability in Cloudflare's Containers service, reported by Oren Yomtov through HackerOne on September 4, exposed residual data from one customer's containers to another customer on the same physical host. The flaw wasn't in network boundaries or authentication logic. It was in storage block reuse policy: a thin provisioning pool configured to skip zeroing 64 KiB blocks on reallocation.
This isn't a theoretical edge case. Researchers found residual material on 18 of 24 container placements and across 20 of 22 underlying nodes tested. The recovered data included directory structures, database pages, and structurally complete SQLite databases.
Why These Mistakes Keep Happening
Multi-tenant isolation failures often occur because teams focus on obvious boundaries like network and authentication, while overlooking lower-level resource sharing. Storage block allocation, memory page reuse, CPU cache timing, and disk snapshot handling all create cross-tenant exposure risks that don't show up in penetration tests focused on application logic.
The problem worsens when infrastructure teams optimize for performance. Zeroing storage blocks before reallocation has a measurable cost. Skipping that step speeds up container startup. The security trade-off isn't visible until someone writes a proof-of-concept that reads the unzeroed space.
Mistake 1: Assuming Network Isolation Equals Data Isolation
Why it happens: Your architecture diagrams show clean separation between tenant networks. VLANs, security groups, and firewall rules all enforce boundaries. It feels complete.
The consequence: Network isolation doesn't protect against storage-layer leakage. When a container's root disk is deleted, physical blocks return to a shared pool. If those blocks aren't zeroed, the next tenant to receive them can read residual data by writing partially to a block and reading the unwritten portion.
The fix: Map every shared resource layer in your infrastructure. For each layer (network, compute, storage, memory), document the isolation mechanism and the data sanitization process. Storage requires explicit zeroing or cryptographic erasure. Don't rely on delete operations to scrub data; verify that block reallocation includes a sanitization step.
Mistake 2: Treating Thin Provisioning as a Pure Performance Win
Why it happens: Thin provisioning lets you overcommit storage and allocate blocks on demand. It's faster than pre-allocating full volumes, and it reduces waste. The storage team enables it for efficiency.
The consequence: Thin provisioning pools serve workloads belonging to multiple customer accounts. Without block zeroing, a 64 KiB block previously used by one tenant can be partially allocated to another. Writing 4 KiB to an unused region triggers block allocation, but only those 4 KiB get overwritten. The remaining 60 KiB stay intact and readable.
The fix: If you use thin provisioning in a multi-tenant environment, enforce block zeroing at the storage layer. This isn't optional. Configure your storage backend to zero blocks on deallocation or before reallocation. Test it: deploy a container, write known patterns to disk, delete the container, deploy a new container as a different tenant, and attempt to read the old patterns. If you can, your zeroing policy isn't working.
Mistake 3: Skipping Segmentation Testing at the Storage Layer
Why it happens: Your segmentation testing focuses on network paths. You verify that Tenant A can't reach Tenant B's API endpoints or database connections. Storage isolation doesn't fit neatly into that testing model.
The consequence: You miss vulnerabilities like this one entirely. The researchers didn't exploit a network flaw or bypass authentication. They allocated containers, wrote partial blocks, and read the unzeroed remainder. Standard penetration testing wouldn't catch it because it requires knowledge of the underlying storage architecture.
The fix: Extend your segmentation testing to cover storage isolation. For container platforms, this means:
- Deploy containers as different tenant identities on the same host
- Write identifiable data patterns to disk in the first container
- Delete the first container and verify block deallocation
- Deploy a second container as a different tenant
- Attempt to recover the original patterns through partial writes and reads
Document this test in your security validation procedures and run it whenever you change storage backends or provisioning policies.
Mistake 4: Relying on Post-Incident Log Analysis to Prove Non-Exploitation
Why it happens: After discovering a vulnerability, you search logs for evidence of exploitation. If you find none, you conclude that no customer data was exposed.
The consequence: This vulnerability wouldn't leave obvious traces. An attacker reading residual blocks doesn't generate failed authentication attempts, unusual API calls, or cross-tenant network traffic. The attack surface is in storage block allocation, which typically isn't logged at the granularity needed to detect partial block reads.
The fix: Design observability into isolation boundaries before incidents occur. For storage systems in multi-tenant environments, log block allocation patterns, track which tenant identities receive blocks from the free pool, and monitor for unusual read patterns in newly allocated storage. You can't rely on absence of evidence; you need evidence of absence, which requires instrumentation that captures the right signals.
Mistake 5: Treating Automated Mitigation as a Substitute for Customer Notification
Why it happens: Cloudflare applied fixes automatically without requiring customer action. That's operationally sound. But it creates a transparency gap: customers don't know their data may have been at risk.
The consequence: If your organization stores Cardholder Data or processes payment transactions in containers, you need to know about cross-tenant exposure risks even if the vendor mitigated them. PCI DSS Requirement 12.10.1 requires incident response plans that address unauthorized access to Cardholder Data. "The vendor fixed it automatically" doesn't satisfy your obligation to assess whether a breach occurred.
The fix: When you use third-party container platforms for payment processing or Cardholder Data environments, your vendor contracts must include notification requirements for isolation failures. Even if the vendor applies fixes automatically, you need details: what data could have been exposed, what time window was affected, and what evidence exists (or doesn't exist) of actual exploitation. This isn't optional under PCI DSS; it's part of maintaining your compliance posture.
Prevention Checklist
Before you deploy multi-tenant container infrastructure:
- Document every shared resource layer (network, storage, memory, CPU)
- Verify that storage backends zero blocks before reallocation to different tenants
- Test thin provisioning configurations for residual data exposure
- Extend segmentation testing to cover storage isolation, not just network paths
- Instrument storage allocation to detect unusual patterns in block reuse
- Establish vendor notification requirements for isolation boundary failures
- Review PCI DSS Requirement 12.10.1 incident response obligations if you handle Cardholder Data
- Run storage isolation tests whenever you change provisioning policies or storage backends
Cloudflare completed all mitigation actions by September 19, 2026, and found no evidence of exploitation. But the vulnerability existed because a storage optimization, skipping block zeroing, created a cross-tenant exposure risk that wasn't visible in standard security testing. Your infrastructure likely has similar gaps. Find them before someone else does.
