Cloudflare has confirmed that a flaw in its Containers platform let one paying customer read data left behind by a completely different customer’s earlier workload. The company disclosed the bug on September 24, 2026, roughly three weeks after a security researcher flagged it through Cloudflare’s bug bounty program. The Cloudflare Containers vulnerability did not require a login, a stolen key, or a phishing email. It only required an aligned 4 KB write to the right spot on a shared disk, and 60 KB of a stranger’s data would come back.
Cloudflare says it found no sign that anyone other than the reporting researcher and its own engineers ever used the technique. But its own internal audit turned up residual data on 18 of 24 tested placements and 20 of 22 underlying servers spanning four continents. That gap, between “we found no evidence of abuse” and “the exposure was real and widespread,” is the story here. It is also a preview of the kind of bug that will keep surfacing as more workloads pile onto shared, ephemeral cloud infrastructure.
What Cloudflare Disclosed on September 24
Oren Yomtov, a researcher at the security firm Accomplish, reported the issue through Cloudflare’s HackerOne bug bounty program on September 4, 2026, at 15:26 UTC. Cloudflare shipped an initial mitigation within three days, completing it on September 7 at 06:13 UTC. Full remediation, which involved rebuilding storage across its fleet, wrapped up on September 19 at 15:03 UTC. Cloudflare published its technical writeup five days later, on September 24, on the company blog.
The bug sat in Cloudflare Containers, the platform the company built to let Workers customers run full container workloads alongside its edge functions. It also touched Cloudflare Sandboxes, a separate product built on top of the same container infrastructure. Both services pulled from the same pool of shared physical disks, and both inherited the same underlying storage bug. No CVE identifier has been assigned to the flaw as of this writing, which is itself notable: a bug capable of leaking database contents between paying customers on a major cloud platform went out without the standard tracking number security teams use to triage exposure.
Timeline: From Bug Report to Public Disclosure
The gap between discovery and disclosure ran about three weeks. Here is how Cloudflare’s own account breaks down:
| Date (2026) | Event |
|---|---|
| September 4, 15:26 UTC | Oren Yomtov (Accomplish) reports the flaw via Cloudflare’s HackerOne bug bounty program |
| September 7, 06:13 UTC | Cloudflare completes an initial mitigation blocking the known exploit path |
| September 14 | Cloudflare confirms the original proof-of-concept no longer functions |
| September 19, 15:03 UTC | Cloudflare finishes retiring and rebuilding affected container disks and cached image snapshots |
| September 24 | Cloudflare publishes its public writeup and remediation summary |
| September 25 | Security outlets, including The Hacker News and Cyber Security News, pick up the disclosure |
How Container Storage Normally Keeps Tenants Apart
Running thousands of customer containers on shared hardware only works if the platform can hand out storage fast and reclaim it just as fast when a container shuts down. Cloudflare, like most container platforms, leans on Linux’s device mapper thin provisioning system, known as dm-thin, to do this. Instead of carving out a fixed disk for every container in advance, dm-thin allocates storage in blocks only when a container actually writes data, then returns those blocks to a shared pool once the container is gone.
That reuse is where the risk lives. When a new container gets handed a block that a previous, unrelated container used, the platform has to make sure every byte of that block gets wiped before the new tenant can touch it. Skip that step, even partially, and the new container can end up sitting on top of someone else’s leftovers. Cloudflare’s flaw traces back to exactly that shortcut.
Inside the Bug: skip_block_zeroing and the 60 KB Gap
Cloudflare’s container disks used a dm-thin configuration option called skip_block_zeroing, set to speed up provisioning by skipping the step that clears a block before handing it to a new owner. dm-thin allocates in 64 KB units. Cloudflare’s own writeup, reviewed for this article, describes the exploit mechanics plainly: a container would write one aligned 4 KB block into the free region it had just been given, forcing dm-thin to allocate the underlying 64 KB physical block. The 4 KB the attacker wrote was new. The remaining 60 KB belonged to whoever had used that block before, and it was still sitting there, fully readable.
Why a 4 KB Write Exposed 60 KB of Old Data
The math is what makes this bug ugly. A single small, deliberate write triggered allocation of an entire 64 KB block, and only a fraction of that block ever got overwritten. The other 93.75% of it could be read back with a raw device read, no privilege escalation required, no credentials needed. Cloudflare’s audit later found that recovered blocks contained directory structures, database pages, and in some cases fully intact SQLite database files.
Sandboxes Inherited the Same Flaw
Because Cloudflare Sandboxes runs on the same container infrastructure, it carried the identical exposure. Any customer running untrusted or ephemeral code through Sandboxes for AI agent execution or code interpretation was subject to the same storage reuse problem as a standard Containers workload.
# Conceptual illustration of the risky dm-thin config (not Cloudflare's exact setup)
lvcreate --type thin-pool --skip_block_zeroing y \
--name shared-pool --thinpool tp0 vg_containers 500G
# With skip_block_zeroing enabled, newly allocated 64KB blocks
# are handed to the next tenant WITHOUT clearing prior contents.
# A partial write (e.g. 4KB) leaves the remaining 60KB intact.The Scope: What Cloudflare’s Own Audit Found
Once Cloudflare understood the mechanism, it went looking for how far it reached. The company sampled six production placements and inspected every testable directory block it could reach, then repeated similar checks across a wider set of nodes. The numbers Cloudflare published paint a picture of a bug that was not a one-off lab curiosity:
| Audit metric | Cloudflare’s finding |
|---|---|
| Testable directory blocks examined | 5,614 |
| Distinct foreign directory inodes found | 2,700 |
| Placements showing residual data | 18 of 24 |
| Underlying nodes affected | 20 of 22 |
| Geographic spread of affected nodes | 4 continents |
| Block size involved | 64 KB (thin-pool allocation unit) |
| Minimum write needed to trigger exposure | 4 KB, aligned |
Roughly three-quarters of the placements Cloudflare checked showed evidence of cross-tenant residue. That is a far cry from a narrow, theoretical edge case. It is the kind of number that turns a single bug bounty report into a fleet-wide remediation project.
Who Could Have Exploited This, and the Limits Attackers Faced
Exploiting the Cloudflare Containers vulnerability was not trivial, and it was not something a random visitor to a website could trigger. It required an active Workers Paid account and the ability to deploy a container workload capable of writing raw data to disk and reading it back. Cloudflare’s automatic workload placement also worked against attackers in one specific way: nobody could pick their target. There was no way to choose a victim, a specific host, or a particular customer’s workload in advance. An attacker running the technique repeatedly would eventually land on blocks holding someone else’s data, but blind, with no control over whose.
That randomness limited the bug’s usefulness for a targeted attack against one named company. It did nothing to limit its usefulness for opportunistic data harvesting, where an attacker cares less about whose data they get and more about getting anyone’s.
Cloudflare’s Fix, Cleanup, and Why It Took Two Weeks
Cloudflare’s fix had two parts. The fast part, done within three days of the report, removed the skip_block_zeroing option so new block allocations would clear old data before handing it to a new tenant. The slow part took twelve more days: retiring every running container disk that had ever operated under the old configuration and deleting cached image snapshots created before the mitigation went live. You cannot patch around residual data already sitting on disk. You have to find it and destroy it, across a global fleet, without breaking active customer workloads in the process.
Cloudflare says customers do not need to take any action themselves. The company handled remediation entirely on its own infrastructure, which is standard for a provider-side storage bug rather than a customer misconfiguration.
No Evidence of Exploitation Is Not the Same as Proof of Safety
Cloudflare checked its retained telemetry and found only the researcher’s testing and its own engineers’ verification runs. No other party appears to have used the technique, based on what the company can see. That is reassuring, but it comes with a real caveat: telemetry only shows what a platform logs, and a well-crafted raw read of a storage block does not necessarily look like an attack in standard access logs. Absence of evidence in a system that was not built to detect this specific technique is weaker proof than customers might assume.
For any customer that stored sensitive data, credentials, or customer records inside a Containers or Sandboxes workload between whenever the flaw was introduced and September 19, the honest answer is that Cloudflare cannot fully rule out exposure. It can only say it found no trace of misuse.
How This Compares to Past Cloud Isolation Failures
Cross-tenant storage and isolation bugs are not new, and Cloudflare’s incident sits in a recognizable lineage. In 2021, Palo Alto Networks’ Unit 42 disclosed Azurescape, a flaw in Microsoft’s Azure Container Instances that let a malicious container escape its own boundary and potentially access other customers’ containers running on the same cluster. In 2019, a runc container runtime bug tracked as CVE-2019-5736 let a malicious container overwrite the host runc binary, opening a path to host takeover across Docker and Kubernetes environments industry-wide. More recently, Google patched its own container escape flaw in GKE, nicknamed Fragnesia and tracked as CVE-2026-46300, which let attackers break out of containerd and gain root on nodes.
What sets Cloudflare’s bug apart from Azurescape and the runc flaw is the mechanism. Those were escape bugs, where a container broke out of its own sandbox. Cloudflare’s issue was a passive data-remnant bug, where a properly contained container simply inherited unwiped storage. No escape, no privilege boundary crossed. Just a shared disk that did not get cleaned between tenants.
| Incident | Year | Root cause | Mechanism |
|---|---|---|---|
| Azurescape (Azure Container Instances) | 2021 | Weak cluster tenant isolation | Container escape to shared cluster |
| runc host takeover (CVE-2019-5736) | 2019 | Runtime binary overwrite | Container escape to host |
| GKE Fragnesia (CVE-2026-46300) | 2026 | Containerd flaw | Container escape, root on node |
| Cloudflare Containers cross-tenant flaw | 2026 | skip_block_zeroing in dm-thin | Residual data on reused disk blocks, no escape |
Cloudflare Containers vs Fargate, Cloud Run, and Container Apps: The Competitive Stakes
Cloudflare pitched Containers as a faster, cheaper way to run full workloads at the edge, competing directly against AWS Fargate, Google Cloud Run, and Azure Container Apps. Those three providers have years more operational history running multi-tenant container storage at scale, and each has had its own isolation scares along the way. The comparison that matters to a buyer evaluating serverless containers right now is not which platform has never had a bug. None of them can honestly claim that. It is which platform found and disclosed the bug with real detail, and on that count Cloudflare’s writeup, complete with exact byte counts and node-level audit data, is unusually transparent for a hyperscale storage incident.
That transparency will not erase the competitive damage entirely. Enterprise buyers running compliance-sensitive workloads tend to weigh disclosed incidents against a provider’s track record, not just its honesty in the moment. Cloudflare has now logged multiple public infrastructure incidents in 2026, and a cross-tenant storage bug on a relatively newer product line, Containers, gives AWS and Google sales teams a fresh talking point when they compete for workloads that Cloudflare was starting to win on price and edge latency.
Market Impact: Does This Slow Serverless Container Adoption?
Probably not broadly, but it will slow adoption in specific segments. Serverless containers have been one of the fastest-growing categories in cloud computing precisely because they let teams skip the operational overhead of managing their own Kubernetes clusters. That value proposition survives a single, promptly disclosed and fixed bug. What does not survive as easily is trust from regulated industries, healthcare, finance, and government contractors, where a cross-tenant data exposure, even one with no confirmed victim, can trigger internal security reviews and vendor risk reassessments that take months to clear.
Expect procurement teams at larger enterprises to start asking cloud vendors a new, more specific question in security questionnaires: how exactly do you guarantee storage block zeroing between tenants, and can you prove it. Vendors that can answer with a clear technical policy will have an edge over those that answer with marketing language about isolated infrastructure.
What Enterprise and Compliance Teams Should Do Now
Cloudflare says no customer action is required, and the fix is already live fleet-wide. That does not mean risk and compliance teams have nothing to do. A few practical steps are worth taking regardless of which cloud provider a team uses:
- Review what sensitive data, if any, ran through Cloudflare Containers or Sandboxes workloads before September 19, 2026, and assess exposure under existing incident response procedures.
- Ask any serverless container vendor, not just Cloudflare, whether they use thin provisioning with block-zeroing disabled anywhere in their storage stack.
- Add storage-reuse and block-zeroing questions to vendor security questionnaires and SOC 2 review cycles going forward.
- Avoid storing long-lived secrets or credentials directly on container-local disk in any multi-tenant serverless platform. Use short-lived tokens and external secret managers instead.
- Watch for Cloudflare’s post-incident review, which the company has historically published in more depth than its initial disclosure.
Predictions: Where Multi-Tenant Container Security Goes From Here
A few things are likely to follow from this disclosure over the next several months:
- Other cloud providers will quietly audit their own dm-thin and copy-on-write storage configurations for similar zeroing shortcuts, whether or not they say so publicly.
- Bug bounty payouts for storage-isolation research on serverless platforms will climb, since this class of bug is now proven to scale across a huge fleet rather than staying theoretical.
- Expect at least one more major provider to disclose a related class of cross-tenant storage bug within the next year, given how common thin-provisioned storage is across the industry.
- Cloudflare will likely publish a deeper post-incident retrospective, following the pattern it set after its 2026 outage reports, to rebuild confidence in Containers specifically.
- Cloud concentration and systemic risk conversations among regulators will start citing storage-isolation bugs like this one alongside outages as evidence that shared infrastructure carries correlated risk across otherwise unrelated customers.
Frequently Asked Questions
What exactly was the Cloudflare Containers vulnerability?
A flaw in how Cloudflare’s Containers platform reused disk storage between customers. A configuration setting called skip_block_zeroing meant that when a new container was handed a previously used 64 KB storage block, the block was not fully cleared, letting a small write expose the remaining data from a prior, unrelated tenant.
Was Cloudflare Sandboxes also affected?
Yes. Sandboxes runs on top of the same Containers infrastructure, so it inherited the identical storage reuse flaw.
Did Cloudflare assign a CVE to this bug?
No CVE identifier had been published as of the company’s disclosure on September 24, 2026.
Do I need to do anything as a Cloudflare customer?
Cloudflare says no customer action is required. The company completed remediation across its fleet on September 19, 2026, including retiring old container disks and cached image snapshots.
Could an attacker target a specific company’s data with this bug?
No. Cloudflare’s automatic workload placement meant an attacker could not choose a victim, host, or specific workload in advance. Exploitation was possible but effectively random.
Who found the Cloudflare Containers vulnerability?
Oren Yomtov, a security researcher at the firm Accomplish, reported it through Cloudflare’s HackerOne bug bounty program on September 4, 2026.
How does this compare to other cloud container escape bugs?
It is different in kind. Bugs like Azurescape on Azure Container Instances or the runc CVE-2019-5736 flaw let a container break out of its sandbox entirely. Cloudflare’s bug did not involve any escape. It was a passive storage cleanup failure that left old data readable inside a properly contained new workload.
Does this affect Cloudflare’s other products, like Workers or R2?
Cloudflare’s disclosure describes the flaw as specific to Containers and Sandboxes storage. It does not describe impact to standard Workers functions or R2 object storage.
