Cloudflare says it has fully fixed a vulnerability in Cloudflare Containers and Cloudflare Sandboxes that could have let one customer read leftover disk data belonging to another. The company states it found no evidence that customer data was compromised and, in the disk telemetry it reviewed, no sign of malicious exploitation. The issue was reported on September 4, 2026 through Cloudflare's bug bounty program by Oren Yomtov, a security researcher at Accomplish.
The flaw sat in the storage layer beneath Containers, which run on multi-tenant infrastructure where customers cannot choose their host. Each container runs inside its own Firecracker virtual machine, with the writable root disk presented as /dev/vdc and managed through Linux device mapper thin provisioning. The affected storage pools used a 64 KiB thin-block size and had the skip_block_zeroing option enabled, so deleted thin volumes handed their blocks back to a pool shared across customer accounts. Unmapped regions were returned as zeroes without a physical block being allocated.
A proof of concept showed the consequence: writing a single aligned 4 KiB block into each 64 KiB region left the other 60 KiB untouched, and a raw-device read could surface bytes the new container never wrote. The attack could not be aimed at a particular customer, workload, host, or data, and residual material was not guaranteed to be present. The submission included counts, block offsets, sizes, checksums, and truncated hashes, but no third-party filenames, identifiers, credentials, hostnames, or addresses.
Validation relied on ext4 directory block checksums using the metadata_csum feature. Across six production placements, all 5,614 testable directory blocks were checked, and none were attributed to the researchers' own filesystem. Checksums identified 2,700 distinct foreign directory inodes, while a control test correctly attributed all 162 deliberately created blocks. Residual data turned up on 18 of 24 placements and 20 of 22 underlying nodes, spanning four continents. Recovered block types included directory structures, database pages, and SQLite databases that were structurally complete, though the scripts reported only aggregate counts and format checks rather than file contents.
The potential impact reached across the tenant-isolation boundary, with possible disclosure of filesystem metadata, directory structures, database pages, and application data. An attacker could not reach an actively attached disk, and Cloudflare reports no demonstrated modification of another customer's live data and no demonstrated effect on workload availability. The first mitigation removed skip_block_zeroing from the dm-thin pool configuration across the fleet, and the researchers independently confirmed the proof of concept stopped working.
Cleanup followed: hosts were drained during off-peak hours, virtual machines were restarted, and image caches were cleared, completing across the Containers fleet. Detection signatures built from the relationship between writes and reads were applied to telemetry, and Cloudflare says it found no evidence anyone else used this attack vector. The fix was applied fleet-wide and customers do not need to change any configuration. Historical disk-I/O telemetry showed no malicious exploitation, with attributable activity coming from the researchers and Cloudflare's own engineers. The post was prepared with Oren Yomtov and the Accomplish research team, and the researchers confirmed the recovered data was securely deleted.
The disclosure comes weeks after Cloudflare opened early access on September 3 to its Vulnerability Discovery and Remediation service, an invitation-only offering under Cloudflare Managed Defense that uses OpenAI Daybreak models to help customers spot flaws in their code.
