Test placements with recoverable residual data: 18 of 24 (Source: Cloudflare Containers vulnerability disclosure, blog.cloudflare.com (September 27, 2026))
What the researcher found
Cloudflare disclosed on September 27 that a security researcher, Oren Yomtov of Accomplish, found a way to recover leftover data from other customers' workloads on its Containers platform, reported through Cloudflare's bug bounty program on September 4. Containers run on shared, multi-tenant infrastructure where customers cannot choose the underlying server. Each container's writable disk is built with Linux's dm-thin storage system, which only allocates physical disk space when a container actually writes to it. Cloudflare's configuration told that system to skip zeroing out reused blocks of storage before handing them to a new customer — so a small write into a fresh container could trigger the reuse of a 64 KiB block still holding fragments of a previous tenant's data, and a broader read could recover the rest.
Why the boundary broke, not just what leaked
The technique required an active Workers Paid account and could not be aimed at a specific customer, host, or dataset — Cloudflare's placement logic, not the attacker, determined which server and which recycled blocks were involved, and residual data was not guaranteed to be present. That is a meaningful limitation on exploitability. It does not change what crossed the boundary when data was present: Cloudflare confirmed the recovered material could include filesystem metadata, directory structures, database pages, and in some cases complete SQLite database files belonging to unrelated accounts. For any organization running production data inside shared container or serverless infrastructure, that is the operative fact — isolation between tenants was resting on a single storage-provisioning setting.
How fast Cloudflare closed it
Cloudflare's own timeline shows the report moving quickly through triage: the incident was opened within roughly three hours of the September 4 report, a runtime fix was merged that same night, and the corrected configuration was rolled out fleet-wide by September 7 — about three days after disclosure. That first fix stopped new leaks but did not scrub data already sitting in running container disks or cached image layers, so a second phase followed: Cloudflare drained hosts, restarted virtual machines, and rebuilt cached layers so that all storage was reallocated under the corrected, zeroing configuration. That full cleanup finished September 19, fifteen days after the initial report. Cloudflare says it also built detection signatures from the researchers' proof-of-concept behavior and ran them against historical disk I/O telemetry, and found no activity attributable to anyone other than the researchers and its own engineers conducting authorized testing.
What to ask your own infrastructure team
This was a storage-provisioning default, not an application bug, which is exactly the category of risk that's hardest for a customer to see or audit from outside. Budget-holders whose organizations run workloads on any multi-tenant container, serverless, or VM platform should ask their infrastructure and security leads a few direct questions drawn from this case. First, does any vendor hosting our workloads on shared infrastructure zero out reused storage blocks before reassigning them to a new tenant, and has that setting been verified rather than assumed? Second, when a vendor patches an isolation flaw like this one, do they also confirm that previously created disks and cached data — not just new allocations — get remediated, since Cloudflare needed a distinct second phase for exactly that reason? Third, can our vendors reconstruct historical telemetry far enough back to rule out prior exploitation of a newly discovered technique, the way Cloudflare says it did here? And finally, does our vendor contract or SLA specify disclosure and remediation timelines for infrastructure-layer findings, separate from application-layer vulnerabilities?
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
