Cloudflare Containers is a hosted service for running container workloads on shared infrastructure. Cloudflare disclosed on 24 September 2026 that a storage setting had allowed a new tenant to recover fragments left by a previous tenant on the same machine. The company says it finished fixing the issue by 19 September and found no evidence of malicious exploitation or customer-data compromise in the telemetry it retained.
Key takeaways
- Cloudflare and the discovering researcher describe a cross-tenant data exposure path in Containers and Sandboxes, not access to another customer’s live disk.
- A reused 64 KiB storage block could keep data outside a new tenant’s smaller write. Researchers observed residual material in 18 of 24 test placements.
- Cloudflare says it restored block clearing, retired older disks and cached layers, and completed the fleet cleanup on 19 September. Customers need no service-side patch.
- The absence of detected malicious use is limited by the historical telemetry available to Cloudflare; it is not proof that exposure was impossible.
What the Cloudflare Containers disclosure actually says
Cloudflare’s 24 September technical disclosure says security researcher Oren Yomtov of Accomplish reported the problem through the company’s bug bounty programme on 4 September. Cloudflare Containers gives developers a way to run containerised applications on Cloudflare’s shared infrastructure. Cloudflare Sandboxes, which uses Containers, was also affected. Accomplish’s own account additionally identifies Browser Run as using the same disk implementation. Cloudflare’s post names Containers and Sandboxes, so that broader product scope is the researcher’s statement.
The incident concerns data left in storage blocks after a workload ends. Cloudflare says a customer with a Workers Paid account could potentially recover residual data previously used by another customer’s container if both workloads landed on the same physical host. The customer could not choose a target account, host or workload. The researchers did not demonstrate access to a disk that was still actively attached to another container, nor a way to change that customer’s files or disrupt service.
That distinction matters for security teams. A cross-tenant confidentiality failure is serious even when it does not grant control over another workload. The incident did not involve a conventional escape from a virtual machine into the host. Instead, the trust boundary broke when physical storage was reused. A security review focused only on application permissions or hypervisor isolation could miss that lower layer.
How a recycled storage block crossed the boundary
Cloudflare says writable container root disks used Linux device-mapper thin provisioning, commonly called dm-thin. The affected pool allocated storage in 64 KiB physical blocks. When a container disk was deleted, the blocks it used returned to a pool serving multiple customer accounts. The pool had enabled the skip_block_zeroing setting, which avoided clearing a returned block before reuse.
During controlled testing, a new container wrote a smaller 4 KiB piece into an unused part of its disk and then examined its own raw disk. The new write replaced only part of a newly allocated 64 KiB block. Bytes outside that write could still belong to a previous workload. This is a storage-reuse issue, not evidence that the earlier customer was still using the disk. The company’s report and The Hacker News’ analysis both explain that the residual bytes depended on placement and prior block use.
The researchers said they found foreign material in 18 of 24 container placements and on 20 of 22 underlying machines they tested across four continents. Those figures describe their controlled sample. They do not establish a fleet-wide exposure rate or show how many customers, if any, had data read by a malicious actor. Cloudflare reported directory structures, database pages and structurally complete SQLite databases among the material detected. Accomplish listed Chromium profiles, environment files and credential-related files as types its research identified.
Why the research finding is not a confirmed breach
A potential path to another tenant’s residual data and a confirmed malicious breach are different claims. Cloudflare says the researchers used checks that returned aggregate counts and format evidence while avoiding collection or submission of third-party names, credentials or recovered file contents. Its team created detection signatures based on the proof of concept and its own validation, then searched historical disk-I/O telemetry. According to Cloudflare, the activity it could attribute to this technique came from the researchers and authorised engineers only.
Cloudflare therefore says it has no evidence that customer data was compromised. The phrasing deserves care. BleepingComputer’s report separates the possible exposure from observed misuse, and The Hacker News notes that Cloudflare did not specify the full period covered by its retained records. A clean search through available telemetry supports a narrower conclusion than “no one ever used this.” It also does not erase the researchers’ finding that the isolation boundary could fail.
For customers, the practical task is to keep those two facts together. There is no public evidence of malicious exploitation through this method, according to Cloudflare. At the same time, the flaw created a way for a suitably placed paying tenant to recover material that should have remained isolated. Security communication becomes misleading when it states only the first fact or only the second.
The remediation had two layers
Cloudflare says its initial fix removed the option that skipped block zeroing, restoring clearing before a returned physical block could be reassigned. That stopped the reported new-allocation path. The researchers later told Cloudflare their proof of concept no longer worked. Yet fixing future allocations alone could not automatically erase data already mapped into running root disks or prepared image-layer snapshots on servers.
The company says it therefore retired existing container disks and cleared old cached snapshots across the affected fleet. It drained and restarted machines as part of that process. Its published timeline says the initial rollout was complete by 7 September and the remaining cleanup finished on 19 September. The public disclosure followed on 24 September. GBHackers’ separate report also describes the need to remove older mappings, because a new zeroing policy cannot retroactively sanitise every existing allocation.
Cloudflare added a regression test for the storage lifecycle. The company says the test writes known data, returns the block to the pool and verifies that a new allocation reads as zero. That is more relevant to this specific defect than a broad claim that the container platform is secure. It checks the moment when storage ownership changes, which is precisely where the reported boundary failure occurred.
What customers should do now
Cloudflare says its service-side mitigation is complete and customers do not need to change Containers or Sandboxes settings to receive the fix. That is the immediate product guidance, and it should not be recast as a requirement for every customer to rotate credentials. The public reports do not identify a particular affected customer or a confirmed stolen secret. Broad, unspecific rotation can impose cost without tying the response to evidence.
Organisations with sensitive workloads can still ask Cloudflare for account-specific guidance if their own risk assessment requires it. They can document which applications used Containers or Sandboxes, what categories of data those applications wrote to ephemeral disks, and whether their internal logging would show unusual use of credentials. This is a measured exposure review, not a declaration that those applications were breached.
Cloudflare customers who operate separate infrastructure should also examine their own ephemeral-storage lifecycle. A container namespace, virtual machine and logical volume can all look isolated while the physical backing store retains older bytes. A test of disk handoff should verify what the next tenant can read, not merely that the old volume object was deleted. Our earlier report on Linux kernel security deadlines addresses a different risk, but it reinforces why the underlying layer matters.
India-based startups often use shared cloud platforms to run background jobs, test environments and AI agents. The Cloudflare Containers incident is therefore relevant even without evidence of an India-specific victim. Teams choosing a sandbox service should ask how writable storage is cleared between users, how caches are retired after a fix and what telemetry supports statements about exploitation. The same questions apply to providers outside Cloudflare.
The broader lesson for AI sandbox infrastructure
AI agents frequently execute code in temporary environments. Their users may assume “temporary” means that files disappear when the task ends. The Cloudflare Containers flaw shows why that assumption must be tested at the physical storage-reuse boundary. An agent’s code can be contained from the host and still encounter another tenant’s remnants if the disk layer is configured incorrectly.
This does not imply that all agent sandboxes or all Cloudflare services shared this defect. Cloudflare’s disclosed affected services are Containers and Sandboxes; Accomplish also named Browser Run. It also does not imply that attackers could name a target organisation and retrieve its secrets at will. The exploit depended on host placement and available residual blocks. Precision about scope is essential because security teams make different decisions for a targeted live-data compromise and for a nondeterministic remanence flaw.
The incident also illustrates why optimisation choices require threat-model review. Skipping a disk-clearing step can improve allocation performance, but in a pool shared across customers it changes the confidentiality guarantee. If a provider makes that trade-off, tests need to demonstrate that a different control prevents cross-account reads. In this case, Cloudflare says it removed the skip setting and tested the resulting zeroed reads.
Related controls higher up the stack remain useful but cannot compensate for an uncleared block. Access policies, workload identities and network rules protect normal application paths; they do not rewrite bytes already present on a reused physical extent. Our coverage of workforce AI security controls examines those higher layers. The Cloudflare case is a reminder to test the storage foundation beneath them.
Facts and boundaries
| First report to Cloudflare | 4 September 2026, according to Cloudflare and Accomplish |
|---|---|
| Public disclosure | 24 September 2026, Cloudflare blog |
| Affected services in Cloudflare’s account | Containers and Sandboxes |
| Researcher’s additional scope | Browser Run uses the same disk implementation, according to Accomplish |
| Observed test result | Residual material on 18 of 24 placements and 20 of 22 tested machines, per the joint technical account |
| Fleet cleanup | Completed 19 September 2026, according to Cloudflare |
| Customer action | No configuration change needed for the service fix, according to Cloudflare |
Frequently asked questions
Were Cloudflare customers confirmed breached?
Cloudflare says it found no evidence of malicious exploitation or customer-data compromise in the historical telemetry it retained. The researchers demonstrated that residual material could be recovered in controlled tests. Those statements should be read together.
How did the Cloudflare Containers flaw work?
The shared dm-thin storage pool reused 64 KiB blocks without clearing all earlier bytes. A new tenant’s smaller write could leave readable remnants from a previous container on the same host.
Does a Cloudflare Containers customer need to install a patch?
No. Cloudflare says it completed the fix on its own infrastructure and customers need no configuration change. Customers with unusually sensitive workloads can still seek account-specific guidance.
Did researchers read another customer’s live disk?
No such access was demonstrated. The reported path concerned residual data in blocks returned from deleted disks, and neither the target account nor host could be selected.
Sources
- Cloudflare: technical disclosure and remediation timeline (primary, 24 September 2026)
- Accomplish: researcher account (primary, 24 September 2026)
- The Hacker News: independent report (25 September 2026)
- BleepingComputer: independent report (27 September 2026)
- GBHackers: independent report (25 September 2026)
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
