They found residual material on 18 of 24 container placements and across 20 of 22 underlying nodes tested, including directory structures, database pages, and structurally complete SQLite databases.
How the Containers storage design produced recoverable fragments
Cloudflare’s Containers product — offered to developers on the Workers Paid plan — runs containerized applications alongside Cloudflare Workers. According to the company’s disclosure, the flaw stemmed from “a shared storage pool configured to skip zeroing reused 64 KiB blocks.”
Cloudflare explains the chain of events this way: “When the thin volume backing a container's root disk was deleted, its physical blocks were returned to a pool that served workloads belonging to multiple customer accounts.” If a newly created container wrote only 4 KiB into an unused region of a disk, the allocation could fall inside a reused 64 KiB physical block. Because the pool skipped the zeroing operation, that 4 KiB overwrite left the remaining 60 KiB intact and potentially readable — fragments of files or databases left behind by a previous tenant.
What the researcher found and how the issue was reported
The flaw was reported through HackerOne on September 4 by Oren Yomtov, a security researcher at technology company Accomplish. The researchers’ testing turned up residual material on 18 of 24 container placements and across 20 of 22 underlying nodes, with recoverable artifacts that included directory listings, SQLite databases, Chromium profiles, .env files, and credential files.
Cloudflare and the researchers limited testing to scripted checks that “performed checks and returned aggregate counts, not actual disk contents,” and the Accomplish team did not demonstrate any ability to alter another customer’s data or to disrupt workloads on Cloudflare’s service. That constrained testing is reflected in Cloudflare’s statement that “the vulnerability would potentially have allowed for a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers’ Containers on the same underlying host.”
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildCloudflare’s remediation steps and timeline
Cloudflare removed the configuration setting that caused skipped block zeroing, retired existing container disks, and cleared cached snapshots that might contain old mappings. The company says it completed those mitigation actions by September 19, 2026. The fixes were applied automatically across Cloudflare’s infrastructure, and “customers need to take no action to address the risk,” the company said.
After the remediation, Cloudflare reviewed logs, telemetry, and historical data and reported that it “found no evidence that customer data was exposed via the method described by Accomplish.”
What this means for developers and companies building on Cloudflare, and for Cloudflare customers
- Developers and security teams building backend services, job processors, or code-execution environments on Cloudflare Containers should note the specific mechanism at play: shared physical blocks that were not zeroed before reuse can yield partial reads of prior tenants’ data. In this case the problem manifested when 4 KiB writes landed inside previously used 64 KiB blocks.
- Enterprises and procurement leaders who rely on Workers Paid accounts should be aware that Cloudflare applied the fixes automatically and retired the affected container disks; according to the company’s post-remediation review, it found no evidence of customer data exposure from this method. Customers therefore do not need to take remedial action as a result of this advisory.
- Cloudflare customers on the Workers Paid plan can also take reassurance from the limits of the demonstrated exploit: the researchers did not show any capability to modify another tenant’s files or to control a host, nor did their scripts retrieve full disk contents during testing.
A concise editorial takeaway
The sequence here is straightforward and instructive: a configuration intended to optimize storage reuse left behind recoverable fragments; an external researcher reported the finding via HackerOne on September 4; Cloudflare implemented fixes and completed mitigations by September 19; and a post-fix review found no evidence of exploitation via the demonstrated method. The public record names Oren Yomtov of Accomplish as the reporter and cites specific, measurable results from the tests — numbers and dates that make this a clear example of how targeted inspection, responsible disclosure, and rapid remediation can close a cross-tenant window before it becomes an incident.
Original report: https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/
