Vulnerability Discovery and Reporting

On September 4, 2026, security researcher Oren Yomtov from Accomplish responsibly reported a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes through the official bug bounty program hosted on HackerOne. Cloudflare has fully remediated the issue and confirmed there is no evidence that customer data was compromised during the incident.

The company developed its incident response and technical assessment in close collaboration with Oren Yomtov and the Accomplish security research team. Their detailed report and controlled testing provided the necessary data to validate the issue and deploy a rapid response.

Underlying Storage Mechanism and Mechanics

Cloudflare Containers run workloads on multi-tenant infrastructure, automatically assigning them to eligible servers without allowing customers to select the underlying host. Cloudflare Containers use Linux device mapper thin provisioning to provide each container with a writable root disk inside a dedicated virtual machine powered by the Firecracker virtual machine monitor.

Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region. The affected storage pools utilized a 64 KiB thin-block size. When a thin volume backing a container root disk was deleted, its physical blocks returned to a shared pool serving multiple customer accounts.

The affected pool configuration included a specific option where device mapper thin provisioning skipped zeroing newly allocated blocks before making them accessible. Consequently, when a previously used block was reassigned, a full-block write replaced previous contents, but smaller writes altered only the written portion, leaving the remainder retaining data from the previous owner.

Proof of Concept and Testing Results

Researchers demonstrated that a customer with a Workers Paid account could recover residual disk blocks previously used by containers on the same host. The technique could not target a particular customer, workload, host, or data, and residual data presence was not guaranteed.

The proof of concept identified regions corresponding to free space in the guest ext4 filesystem and wrote a 4 KiB block into each region. This triggered the allocation of a 64 KiB physical block from the shared pool, where the smaller write replaced only a fraction of the block while leaving the remaining unwritten space intact.

Researchers used ext4 directory block checksums to isolate test data from foreign data. Across multiple production placements, they observed residual material including directory structures, database pages, and SQLite databases. Researchers confirmed they used aggregate scripts and securely deleted all recovered data following submission.

Remediation and Mitigation Actions

Cloudflare's primary mitigation removed skip_block_zeroing from the device mapper thin provisioning pool configuration across the entire fleet. This restored the default behavior of clearing newly allocated blocks before exposing them to containers, effectively stopping the reported technique.

Because zeroing new allocations did not automatically sanitize blocks already mapped into existing thin devices or OCI image layer caches, Cloudflare applied additional remediation steps. Customers are not required to make any configuration changes on their side.

An examination of historical disk input-output telemetry revealed no evidence of malicious exploitation. All activity matching the reported technique was directly attributed to the external security researchers and Cloudflare engineers conducting authorized validation tests.

Sources

• Cloudflare BlogHow Cloudflare addressed a cross-tenant data exposure vulnerability in Containers