What is confirmed
A new tenant could receive storage that still contained an earlier tenant’s data
Cloudflare says a security researcher from Accomplish demonstrated that a Workers Paid customer could recover residual data from disk blocks previously used by other customers' Containers on the same physical host. Sandboxes, which are built on Containers, were also affected.
The technique could not select a victim, host, workload, or particular data. It did not read a disk that was still attached to another customer, and the researchers did not demonstrate modification of another customer's active workload. The weakness was nevertheless a cross-tenant confidentiality failure: a legitimate disk allocation could contain bytes the new workload had never written.
Keep the incident statement precise
How the boundary failed
The virtual machine boundary held, but the disk lifecycle did not
Cloudflare Containers use Linux device-mapper thin provisioning for writable root disks. The affected storage pools used 64 KiB blocks with skip_block_zeroing enabled. When a new container wrote only 4 KiB into a newly allocated block, the remaining 60 KiB could retain data from the block's previous owner.
| Lifecycle event | Expected security property | What the incident exposed |
|---|---|---|
| A workload stops | Its data becomes inaccessible to later tenants. | Deleting a thin volume returned physical blocks to a shared pool without guaranteeing that their contents were cleared. |
| A new disk is allocated | Every readable byte belongs to the new tenant or is zeroed. | A partial write could allocate a reused block while leaving the unwritten portion intact. |
| A provider changes configuration | Future and already-created state are both made safe. | Restoring block zeroing stopped new unsafe allocations, but existing disks and cached snapshots still required retirement and cleanup. |
| A customer reviews isolation | Runtime containment and resource handoff are both examined. | A guest did not need to escape its microVM; the host supplied it with data through an authorised block device. |
Provider response
Stopping new exposure and removing old state were separate jobs
Cloudflare removed the option that skipped block zeroing and deployed the runtime correction across the fleet. It then retired running container disks and cleared cached image snapshots created before the mitigation because those resources could retain mappings established under the earlier configuration.
The initial rollout completed on 7 September, the researchers confirmed that their proof of concept no longer worked on 14 September, and Cloudflare completed cleanup of pre-mitigation cached snapshots on 19 September. The sequence matters: a control change can correct future behavior while leaving older resources in an unsafe state.
Defender notes
Use the disclosure to improve cloud and AI-workload assurance
- 1
Inventory where transient workloads handle sensitive data. Identify build runners, browser automation, AI-agent sandboxes, data-analysis jobs, and developer environments that receive source code, customer records, credentials, or regulated data.
- 2
Separate secret delivery from the guest filesystem. Prefer short-lived, scoped credentials delivered only when needed. Where the platform supports it, add authentication outside the sandbox rather than writing reusable secrets into images, environment files, browser profiles, or working directories.
- 3
Ask about the full deletion path. Supplier reviews should cover volumes, snapshots, caches, host-local layers, backups, crash artifacts, and capacity returned to shared pools—not only the API call that deletes a workload.
- 4
Test isolation across time. Validation should check what a new workload can read after an earlier workload is destroyed. Runtime escape testing alone does not exercise residual-data risk.
- 5
Distinguish mitigation from cleanup. For provider incidents, record when new exposure stopped, when previously created resources were retired, what telemetry was available, and what period could not be reconstructed.
- 6
Plan for provider-side confidentiality incidents. Document who evaluates possible data classes, rotates exposed credentials, assesses contractual notifications, and requests provider evidence when customers cannot inspect the underlying hosts themselves.
Detection and evidence
Customers may have less telemetry than the provider
This technique operated below the guest workload, so a customer's application and container logs might not show another tenant reading released storage. That makes provider-side allocation and disk-I/O telemetry important evidence. Security requirements should therefore specify not only isolation controls, but also the records retained to investigate a failure in those controls.
For internal platforms using thin provisioning or reusable worker hosts, defenders can monitor raw block-device access from guests, unusual read-after-small-write patterns, unexpected access to free filesystem regions, and failures in block-zeroing or pool-sanitisation tests. Those signals are architecture-specific and should be validated in a controlled environment before being treated as reliable detections.
Editorial note
How this analysis was prepared
This topic was surfaced by The Cyber Security Hub newsletter. Threat Field Notes independently reviewed Cloudflare's incident report, limited the claims to the affected products and evidence Cloudflare disclosed, and used the event to derive defender questions about storage reuse, provider evidence, and secrets in transient workloads. The newsletter was treated as a lead rather than copied as article text.