Cloudflare has fixed a storage isolation flaw in Cloudflare Containers that could allow one paying customer to read residual disk data left behind by another customer’s deleted container. The issue did not involve direct access to live workloads, and Cloudflare says customers do not need to take action, but the incident is a useful reminder that multi-tenant container platforms depend on careful cleanup of storage as much as process isolation.
According to the report, the weakness affected Cloudflare Containers and Cloudflare Sandboxes, a service built on Containers for running untrusted code such as code produced by AI agents. Security researcher Oren Yomtov of Accomplish reported the issue through Cloudflare’s bug bounty program on September 4. Cloudflare later remediated the behavior, retired affected container disks, cleared caches, and said it found no evidence of exploitation outside authorized research and internal testing.
What happened
The flaw centered on how container disks were provisioned and recycled. Each container received storage based on Linux thin provisioning, where disk space is allocated in blocks rather than fully reserved upfront. When a container was removed, its disk blocks were returned to a shared pool that could later be assigned to a different customer’s container on the same infrastructure.
In a correctly configured multi-tenant environment, reused disk blocks should be wiped or zeroed before another tenant can read them. In this case, the relevant pool was configured to skip that wipe step. If a new container wrote only a small amount of data into a reused block, the unwritten portion of that block could still contain bytes from the previous tenant’s container.
The researchers demonstrated the issue by writing a small amount of data into unused space and then reading back the full underlying block. Because only part of the block had been overwritten, the remaining bytes could expose residual data. Reported examples included file-system structures, SQLite database pages, browser profile material, environment files, and credential-like files. The researchers stated that they did not disclose third-party secrets and that recovered material was handled privately and deleted after reporting.
Why this matters
The practical risk is not that an attacker could select a specific victim or browse another customer’s active filesystem. Cloudflare said the attacker could not choose whose data they received, and the issue related to leftover data from earlier containers rather than live workloads. That reduces targeting precision, but it does not make the issue minor.
Random residual data can still be sensitive. Application containers often store temporary database files, configuration files, tokens, service credentials, logs, browser artifacts, and build outputs. Even fragments can be useful if they contain secrets, internal paths, customer identifiers, or authentication material. In a platform used to run untrusted or AI-generated code, the ability for one tenant to inspect another tenant’s leftover bytes is especially serious because the service boundary is the central security promise.
This incident also highlights a class of cloud risk that can be easy to overlook. Container isolation is often discussed in terms of namespaces, kernels, seccomp profiles, privileges, and runtime escapes. But storage lifecycle controls are just as important. When infrastructure rapidly creates and destroys workloads, secure deallocation must be reliable, enforced by default, and monitored.
Cloudflare’s response
Cloudflare reportedly fixed the issue in stages. First, it re-enabled wiping for newly allocated blocks, which stopped the proof-of-concept technique used by the researchers. However, that alone did not clean every block already mapped into running container disks or image-layer caches. Cloudflare then retired running container disks and cleared prepared image caches, draining and restarting servers during lower-traffic periods. The cleanup was completed before public disclosure.
Cloudflare also reviewed retained disk activity records using signatures based on the researchers’ proof of concept and its own reproduction of the attack. The company said it found only activity from the researchers and Cloudflare engineers. The public reporting does not make clear exactly how long the unsafe configuration existed, so defenders should treat the incident as a platform-side exposure rather than something customers can fully validate from their own application logs.
Guidance for cloud and container users
Cloudflare says customers do not need to take action, and for many users there may be no practical customer-side remediation. Still, teams that used affected services should review their own risk posture and reduce future exposure from residual-data events.
Start by assuming that temporary files can become sensitive. Avoid writing long-lived secrets to local disk inside short-lived containers unless it is necessary. Prefer runtime secret injection mechanisms that avoid persistent files where possible, and ensure applications clean up temporary credentials, session artifacts, and database exports after use.
Rotate credentials if your workloads stored high-value secrets on local container disks and your risk tolerance is low. That does not mean every customer must rotate everything immediately, but secrets placed in environment files, browser profiles, local SQLite stores, or application config files deserve closer attention.
Review logging and build behavior. CI tasks, browser automation, scraping jobs, AI-agent sandboxes, and test runners often leave behind more sensitive residue than teams expect. They may cache tokens, cookies, screenshots, downloaded documents, debug dumps, package registry credentials, or test databases. Treat ephemeral compute as potentially recoverable unless the platform provides strong guarantees and you have validated your own cleanup practices.
Finally, ask vendors about storage reuse controls in multi-tenant services. Useful questions include whether deleted blocks are zeroed before reuse, whether image-layer caches are tenant-isolated, how long disk activity telemetry is retained for investigations, and whether storage lifecycle settings are continuously audited.
Bottom line
The Cloudflare Containers flaw appears to have been fixed, and there is no public evidence that the reported technique was abused outside the coordinated disclosure process. The broader lesson is clear: in multi-tenant cloud services, secure isolation includes the afterlife of data. Containers may be temporary, but the blocks they leave behind must be treated as sensitive until they are wiped.
Source: The Hacker News source