Could a customer on your cloud platform access another tenant's database? Cloudflare recently disclosed a cross-tenant data exposure vulnerability that highlights the risks when storage management skips critical steps. The flaw, reported through HackerOne by security researcher Oren Yomtov, allowed Workers Paid customers to recover residual data from other customers' containers on shared infrastructure. Cloudflare completed mitigation by September 19, 2026, with no evidence of actual customer data exposure.
For risk managers evaluating cloud providers or operating multi-tenant environments, this incident raises a fundamental question: how do you verify that tenant isolation controls extend all the way to the storage layer?
What This Checklist Covers
This checklist addresses the technical and contractual controls you need to audit when assessing tenant isolation in cloud services. It's designed for teams evaluating cloud service providers, reviewing internal multi-tenant architectures, or responding to underwriting questionnaires about shared infrastructure risks.
You'll verify storage management practices, confirm vulnerability disclosure pathways, and document the control evidence your insurers and auditors expect.
Prerequisites
Before you start, gather:
- Your cloud service provider's SOC 2 Type II report (look for CC6.1 controls on logical access)
- Architecture diagrams showing storage pools, volume management, and tenant boundaries
- Your provider's vulnerability disclosure policy and HackerOne (or equivalent) program documentation
- Incident response playbooks defining cross-tenant exposure scenarios
- Your Stand-Alone Cyber Policy or Cyber Endorsement to confirm coverage for third-party cloud provider failures
If you're auditing your own infrastructure, you'll need access to storage configuration logs and block allocation settings.
Checklist Items
1. Confirm block zeroing is enabled on all shared storage pools
Check that your provider (or your team) has configured storage systems to zero all reused blocks before reallocation. The Cloudflare incident occurred because a pool was configured to skip zeroing 64 KiB blocks, leaving 60 KiB of prior tenant data readable after a 4 KiB write.
Done looks like: A configuration audit trail showing "zero-on-delete" or equivalent settings enabled across all storage tiers, with no exceptions for performance optimization.
2. Verify thin provisioning does not bypass isolation controls
Thin volumes improve storage efficiency but can create cross-tenant risk if physical blocks return to a shared pool without sanitization. Confirm that deletion of a tenant's volume triggers immediate block reclamation with zeroing.
Done looks like: Documentation from your provider showing that thin volume deletion invokes a secure erase process before blocks return to the allocation pool, not just a metadata update.
3. Document the vulnerability disclosure program scope
Confirm your provider operates a bug bounty or coordinated disclosure program that covers tenant isolation flaws. The Cloudflare issue was identified through HackerOne, demonstrating the value of external security research.
Done looks like: A public vulnerability disclosure policy with defined scope, response SLAs, and a track record of disclosed and remediated issues. Ask for the last 12 months of HackerOne or equivalent submissions related to tenant isolation.
4. Test for residual data in new container or VM allocations
If you operate multi-tenant infrastructure, run allocation tests similar to what Accomplish performed: provision a new container, write a small amount of data, and scan unwritten regions for readable content.
Done looks like: Test results showing only zeroed blocks in unwritten regions across at least 20 allocation attempts on different physical hosts. Any readable residual data is a failed test.
5. Confirm tenant isolation extends to filesystem metadata
Cloudflare noted that the flaw could expose "filesystem metadata, directory structures, database pages, and application data." Verify that your storage layer prevents cross-tenant access to metadata, not just file contents.
Done looks like: Architecture documentation showing that filesystem metadata (inodes, directory listings, allocation bitmaps) is encrypted or isolated per tenant, with no shared metadata structures.
6. Review your provider's incident response timeline
Cloudflare mitigated the issue within 15 days of disclosure. Evaluate whether your provider's SLA for critical vulnerabilities meets your risk tolerance.
Done looks like: A contractual SLA specifying remediation timelines for tenant isolation flaws (e.g., "critical vulnerabilities affecting tenant boundaries will be mitigated within 14 days of validated disclosure").
7. Audit log retention for cross-tenant access attempts
Cloudflare examined logs and telemetry to confirm no exploitation occurred. Verify your provider retains sufficient logs to detect unauthorized cross-tenant access.
Done looks like: Log retention policies covering at least 90 days of storage-layer access events, with alerting on anomalous read patterns (e.g., a tenant reading blocks from volumes they don't own).
8. Confirm your Cyber Extortion Coverage applies to cloud provider failures
If a cross-tenant flaw exposes your data through your provider's infrastructure, verify your policy covers the resulting breach notification, forensics, and regulatory costs.
Done looks like: Policy language confirming that "third-party service provider failures" trigger coverage, with no exclusion for shared infrastructure risks. Check for sublimits on Contingent Business Interruption.
9. Validate automatic remediation for infrastructure-level fixes
Cloudflare applied fixes automatically without requiring customer action. Confirm your provider can patch storage-layer vulnerabilities without service disruption.
Done looks like: A change management process showing that storage configuration updates can be deployed with zero downtime and no customer intervention required.
10. Request evidence of retired container disks and cleared snapshots
After fixing the block zeroing issue, Cloudflare retired existing container disks and cleared cached snapshots. Confirm your provider follows similar practices after remediating storage vulnerabilities.
Done looks like: Incident closure documentation showing that all potentially affected storage volumes were decommissioned or scrubbed, not just patched in place.
Common Mistakes
Assuming encryption solves tenant isolation. Encryption at rest protects against physical theft but doesn't prevent cross-tenant data leaks if blocks are reallocated without zeroing. You need both.
Treating SOC 2 as sufficient proof. SOC 2 reports often describe controls at a high level. You need to verify the specific storage management settings, not just trust the control description.
Ignoring performance trade-offs. Cloudflare's pool skipped zeroing for performance reasons. If your provider offers "performance-optimized" storage tiers, ask what isolation controls were traded away.
Failing to test your own assumptions. If you operate multi-tenant infrastructure, you can't assume block zeroing is enabled just because it's an industry standard. Test it.
Next Steps
Schedule a quarterly review of your cloud provider's vulnerability disclosure activity. Look for patterns: are they finding and fixing tenant isolation issues proactively, or only after external researchers report them?
Add "storage-layer tenant isolation" to your vendor Underwriting Questionnaire. Ask specific questions about block zeroing, thin provisioning, and residual data testing.
Update your incident response playbook to include a cross-tenant exposure scenario. Define who investigates, what logs you'll need from your provider, and how quickly you'll trigger Breach Notification Requirements if customer data crosses tenant boundaries.
The Cloudflare incident ended well because a researcher found the flaw before an attacker did, and the company fixed it quickly. Your job is to verify that your providers have the controls in place to prevent the issue in the first place.
