Cloudflare’s container fix follows a 64 KiB zeroing failure

Cloudflare has remediated a cross-tenant data-isolation flaw in its Containers service after researchers showed that newly created containers could inherit readable fragments of other customers' deleted disks. The issue affected customers on the Workers Paid plan, which is required to use Containers, and Cloudflare says it completed mitigations on September 19, 2026.

The failure was not a container breakout in the usual sense of taking control of a host. It was a storage-sanitization bug: physical blocks from a deleted container disk could return to a shared pool without being cleared first. A new tenant that received one of those blocks could read data left beyond the part it had written.

Cloudflare says it found no evidence that customer data was exposed through this method after reviewing logs, telemetry, and historical data. That conclusion differs from the researchers' proof that stale data was technically recoverable under test conditions. The researchers used scripts that reported aggregate results rather than collecting disk contents, so the evaluation itself did not retrieve actual customer files.

A 4 KiB write could expose 60 KiB of stale data

The vulnerable configuration skipped zeroing when storage blocks were reused. Cloudflare’s thin-provisioned container disks allocated physical blocks in 64 KiB units, while the researchers could write only 4 KiB into an unused portion of a new disk. If that write caused allocation of a previously used 64 KiB block, the new 4 KiB data replaced only that portion; the remaining 60 KiB could retain readable material from the prior tenant.

Recommended reading

OpenAI says public data; its agents also sent 53 ChatGPT images away

Sergey Kuznetsov • Sep 26, 2026 • 9 min read

“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.”

The storage system did not need to attach or expose an active victim disk. The leak occurred after deletion, when a physical block was recycled across accounts without a full clear operation. The attacker also could not select the target customer or underlying host, which made the technique opportunistic rather than a directed way to retrieve a specific tenant’s data.

The researchers reported finding residual material on 18 of 24 container placements and across 20 of 22 underlying nodes they tested. Reported artifacts included directory structures, database pages, structurally complete SQLite databases, Chromium profiles, .env files, and credential files. Application secrets, database records, filesystem metadata, and browser state could reside in the untouched remainder of an allocation unit.

“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.”

The technical report also says Cloudflare Sandboxes and Browser Run used the same disk implementation and were affected. The flaw was in shared persistent-storage handling, not in an application’s own container configuration. The researchers' disclosure dates the report to Cloudflare to September 4, 2026.

What Cloudflare changed

Cloudflare removed the configuration responsible for skipped block zeroing, retired existing container disks, and cleared cached snapshots that might have retained old mappings. The company applied the infrastructure-side changes automatically; customers do not need to change application code, rotate settings, or redeploy to receive the storage-layer remediation.

The dates clarify an ambiguity in the public descriptions. Accomplish says Cloudflare fixed the issue “shortly after” the September 4 report, while Cloudflare’s stated September 19 completion date covers the full response: disabling the unsafe setting, retiring disks, and clearing potentially stale snapshots. The statements can describe different stages of the same remediation rather than competing timelines.

Exposure was possible; extraction was not demonstrated

The reported test results establish that the isolation boundary could fail and that stale filesystem data was present in reused blocks. They do not establish that any particular customer’s data was taken. The researchers deliberately limited their scripts to checks and aggregate counts, while Cloudflare says its subsequent internal review found no indication of real-world exploitation through this technique.

The reporting describes no way to alter another tenant’s files or interrupt another tenant’s workload. Nor could the researchers read a disk while it was actively attached. A paid customer could potentially provision containers until recycled storage revealed data from another account sharing the same host.

Container isolation depends on storage handling as well as runtime namespaces, virtual machines, or sandbox policy. A correctly isolated process can still inherit another tenant’s data if the underlying block allocator recycles storage without clearing it. Cloudflare’s repair addresses that condition; neither the company nor the researchers published independent post-fix testing results in the material available here.