Cloudflare Erases Reused Container Disks After Cross-Tenant Data Leak Flaw

Cloudflare has fixed a storage-isolation weakness in Cloudflare Containers that allowed one customer’s workload to recover disk fragments left behind by another tenant on the same physical infrastructure.

The flaw also affected Cloudflare Sandboxes, a service built on Containers for executing untrusted code, including programs generated by AI agents. The issue exposed residual application data rather than live, attached storage, but testing showed that recoverable blocks were widely distributed across the production systems examined.

Cloudflare applied the fixes automatically and completed its infrastructure cleanup on September 19, 2026. Customers do not need to take action.

Recycled blocks crossed the tenant boundary

Cloudflare Containers runs containerized workloads for customers with Workers Paid accounts. Common uses include backend applications, job-processing services and isolated code-execution environments.

Cloudflare determines where each container runs, while multiple customer accounts share the provider’s underlying servers and storage resources. That design requires strict separation not only between active workloads, but also when storage is released and later assigned to somebody else.

Accomplish security researcher Oren Yomtov reported the problem on September 4 through Cloudflare’s bug bounty program, identified by BleepingComputer as HackerOne.

The weakness appeared when a container was deleted. Its physical disk blocks returned to a shared pool that could subsequently serve containers belonging to unrelated accounts. That pool was configured not to erase blocks before reuse, even though zeroing was normally the default behavior.

Consequently, allocating a block to a new tenant did not guarantee that every byte had been cleared. Portions untouched by the new workload could still contain information written by the previous user.

A 4 KiB write exposed the rest of a 64 KiB block

The affected storage used Linux thin provisioning and allocated disk capacity in 64-kilobyte blocks. Thin provisioning maps logical storage to physical capacity as needed, avoiding the cost of reserving an entire disk allocation in advance.

The researchers demonstrated a direct consequence of the mismatched allocation and write sizes. A newly created container could write 4 KiB into an otherwise unused disk region and then inspect the complete 64 KiB physical block through raw-disk access.

The new write replaced the first 4 KiB. The remaining 60 KiB could retain data from a deleted container previously assigned the same physical block.

This was not conventional file access through another tenant’s mounted filesystem. Instead, the attacker examined reclaimed storage below that abstraction, looking for recognizable structures in the bytes left behind.

Cloudflare said successful exploitation violated its tenant-isolation boundary. Potentially exposed material included:

• Filesystem metadata and directory structures
• Database pages and complete SQLite database structures
• Application data
• Chromium browser profiles
• .env files
• Files containing credentials

The findings indicate that sensitive information did not need to exist as a complete ordinary file to be useful. Database pages, configuration fragments or directory entries can reveal secrets and operational details even when recovered only partially.

Production tests found remnants across most sampled nodes

The researchers detected residual material in 18 of 24 container placements. They also found it on 20 of the 22 underlying machines or nodes included in their tests, with systems spanning four continents, according to reporting on Cloudflare’s disclosure and the researchers’ results.

Cloudflare reported that recovered blocks included directory structures, database pages and structurally complete SQLite databases. The researchers’ account also identified browser profiles, environment files and credential-related files among the recognizable formats.

Their analysis scripts generated aggregate counts and validated data formats rather than collecting file contents. They said their submission to Cloudflare did not contain third-party names, identifiers, credentials or recovered customer content. Any recovered material was kept private and securely deleted after the report.

Cloudflare’s position is that no real customer data was exposed during the authorized evaluation. Separately, the researchers said they recovered residual material during testing. These statements describe different aspects of the exercise: the tests established that old data structures remained accessible, while the researchers say they avoided retaining or submitting identifiable third-party content.

The issue enabled disclosure, not control of other workloads

The demonstrated impact was limited to confidentiality. The researchers did not show that an attacker could modify another customer’s live files, interrupt a service or gain control of the victim’s container.

The method also could not read a disk while it remained actively attached to another workload. Exploitation depended on physical blocks being released and recycled through the shared storage pool.

Nor could an attacker select a particular victim. Cloudflare controlled container placement, and the reused blocks available to a newly launched workload depended on infrastructure allocation decisions. An attacker could therefore search for residual data, but not request storage previously assigned to a named organization.

That limitation reduces the method’s precision, not the sensitivity of the possible results. Secrets in .env files, credential stores or database pages could still be valuable regardless of which tenant originally created them.

The researchers also said Cloudflare Browser Run used the same disk configuration. Cloudflare’s disclosed scope named Containers and Sandboxes but did not mention Browser Run. It is therefore unclear whether Cloudflare considers Browser Run separately affected or whether its remediation required additional service-specific measures.

Cloudflare found no evidence of exploitation beyond testing

After reproducing the issue, Cloudflare created detection signatures based on the researchers’ proof of concept and its own tests. It then searched retained disk-activity records for matching behavior.

The company found only the authorized activity conducted by the researchers and Cloudflare engineers. Its review of logs, telemetry and historical information reportedly produced no evidence that another party had used the same technique to expose customer data.

However, the available information does not specify how far back the retained records extended. Cloudflare also did not disclose when the unsafe no-zeroing configuration was introduced. The total period during which residual blocks may have been recoverable is therefore unknown.

No public indicators of compromise have been provided for customers to search. Because the relevant evidence existed within Cloudflare’s storage infrastructure and placement systems, individual users may have limited visibility into whether their deleted blocks were ever reallocated.

Fixing allocation was only the first remediation step

Cloudflare initially restored zeroing for newly allocated blocks. That change ensured that storage issued after the fix would be erased before a different tenant could access it.

On September 14, the researchers confirmed that their proof of concept no longer worked. Yet changing the allocation policy did not remove every historical mapping already present in the platform.

Blocks could remain associated with running container disks. Prepared image layers and cached snapshots could also preserve older mappings. Cloudflare therefore retired all active container disks and cleared the relevant caches, draining and restarting servers during quieter operating periods.

The company completed that cleanup on September 19, 2026. Remediation was performed within Cloudflare’s infrastructure, so customers do not need to patch applications, rotate container images or change configuration specifically to receive the fix.

No CVE identifier or formal severity score has been published. The issue is best characterized as a cross-tenant confidentiality failure involving potentially sensitive residual data, rather than a host takeover or destructive container escape.

The researchers described it as their sixth published code-sandbox escape since July, following work involving Anthropic’s Claude Cowork and Claude Code, Cursor’s command-line tool, Docker and OpenAI’s Codex. In this case, however, the proven capability was recovery of recycled disk contents—not arbitrary control over another tenant or the Cloudflare host.