A useful infrastructure review asks two different questions: who can access a workload while it runs, and what can survive after it ends? Storage reuse makes the second question essential for multi-tenant products and agent execution platforms.
The new disclosure, not a new incident
Cloudflare’s 24 September report describes a flaw reported on 4 September, with cleanup completed on 19 September. A 4 KiB write into a reused 64 KiB allocation could leave 60 KiB of another tenant’s data exposed. Remediation restored block zeroing and retired old disks and cached snapshots. Cloudflare reports no evidence of malicious exploitation within retained telemetry, and no customer configuration change is required. The report includes researcher validation; this article has not independently reproduced it.
Why a new disk can contain old bytes
Linux’s dm-thin documentation explains that multiple virtual devices can share one underlying data volume. Allocation maps logical space to physical blocks. The optional skip_block_zeroing setting disables clearing newly allocated blocks; it does not promise that unwritten bytes contain no previous data.
Think of reuse as changing ownership, not necessarily changing every byte. This is a storage-lifecycle problem: an application can enforce authorization correctly and still rely on an unsafe lower-layer handover.
Ephemeral is a lifecycle, not an erasure certificate
Cloudflare’s container lifecycle documentation describes a dedicated VM per container and an ephemeral disk, with a fresh image-defined disk after a sleeping instance restarts. That documents the application-visible lifecycle. It should not be read as a universal claim about every physical storage implementation.
For architecture reviews, separate three contracts: process isolation, data persistence and resource sanitization. Ask which component owns each contract and what evidence demonstrates it. A working login test proves none of the storage handover properties.
A practical test for your own platform
The following is an editorial test design, not a reproduction of the incident and not a test against somebody else’s infrastructure. Use an isolated staging environment you own, two synthetic tenants and non-sensitive marker data.
Start by recording tenant A’s allocation identifier and writing a random marker into its temporary workspace. Exercise normal shutdown, forced termination and deletion. Then allocate tenant B through the supported interface and verify that only B’s expected data is accessible. Include restoration from your own prepared images or snapshots.
For platform operators, add lower-level checks appropriate to the storage driver in a disposable lab. Application-level tests alone cannot prove that unreachable physical blocks were sanitized. Never inspect shared production disks or attempt to retrieve another customer’s content.
Record the runtime version, storage configuration, image lineage and which cleanup path executed. An intermittent test failure is evidence to investigate, not a percentage that can be generalized to all workloads.
Apply the lesson to SaaS and AI agents
Consider an illustrative SaaS service that runs a document-conversion job for each merchant. Its job identifier, temporary files, cached inputs, logs and credentials need explicit ownership. Build a resource inventory around the job rather than assuming that deleting its database row removes its working state.
For an AI agent that runs user-provided code, make the same inventory part of session teardown. Give the session only the credentials it needs, expire them separately, and avoid baking user data into reusable images. These are design recommendations, not a claim that this particular incident exposed every resource listed.
Database tenant isolation remains necessary, but it addresses another boundary. Pair it with observable operations so cleanup failures can be traced without copying sensitive payloads into logs.
Trade-offs and the decision to make
The Kubernetes multi-tenancy guide distinguishes several isolation approaches; namespaces alone are not a complete answer for mutually untrusted tenants. Shared infrastructure and stronger separation involve different operational costs and threat assumptions.
Before optimizing startup latency, define an acceptance gate for reuse: cleanup finished, image lineage approved, credentials expired and validation passed. Measure that path under your own workload. This article provides no measured latency penalty or cost saving.
The architectural takeaway is a question to add to your next design review: can you explain and test the entire transition from one tenant’s last write to the next tenant’s first read?
Official references
These references document the tools discussed. Examples and design decisions are illustrative and should be adapted to the project and its versions.
Prepared by: Noor Yasser
Working through a similar engineering challenge?
I help teams turn architecture decisions into a clear scope and dependable, reviewable implementation.
