Cloudflare Patches Cross-Tenant Data Exposure in Container Infrastructure
Researchers discovered a vulnerability allowing access to residual data in multi-tenant container environments.
1Vulnerability discovery
On September 4, 2026, security researcher Oren Yomtov from Accomplish reported a critical vulnerability affecting Cloudflare Containers and Sandboxes through Cloudflare's bug bounty program. The issue involved potential cross-tenant data exposure in the multi-tenant container infrastructure. Cloudflare worked closely with the researchers to validate and address the issue, finding no evidence of customer data compromise during their investigation.
2Technical root cause
The vulnerability stemmed from Cloudflare's use of Linux device mapper thin provisioning (dm-thin) with skip_block_zeroing enabled. This configuration allowed 64KiB storage blocks to retain residual data when reassigned between containers. A Workers Paid account could potentially recover fragments of previous tenants' data through carefully crafted read operations, though targeting specific data wasn't possible.
3Exploit methodology
Researchers demonstrated the vulnerability by writing 4KiB blocks into ext4 free space regions, triggering allocation of 64KiB blocks from shared pools. Since only the written portion was overwritten, the remaining 60KiB could contain residual data. The proof of concept recovered filesystem metadata, database pages, and complete SQLite structures, though no actual customer content was extracted or retained.
4Validation process
The research team used ext4 directory block checksums to validate the vulnerability across multiple production placements. They tested 5,614 directory blocks, finding 2,700 distinct foreign inodes. Controlled tests confirmed the method's accuracy, with all 162 test blocks correctly attributed. Residual material appeared on 18 of 24 placements and 20 of 22 nodes across four continents.
5Immediate mitigation
Cloudflare's first action was removing skip_block_zeroing from dm-thin pool configurations, restoring default zeroing behavior. This change was verified by researchers as effective. Additionally, Cloudflare retired all running container disks and cleared cached image snapshots containing pre-mitigation allocations. The cleanup process involved draining hosts during off-peak hours and restarting VMs.
6Forensic investigation
Cloudflare analyzed historical disk-I/O telemetry using signatures based on the exploit's characteristic write-read patterns. The review identified only authorized validation activity by researchers and Cloudflare engineers, with no evidence of malicious exploitation. The company maintains that customer data wasn't compromised through this vector.
7Impact assessment
While the vulnerability could have allowed access to residual data across tenant boundaries, attackers couldn't target specific customers or access active disks. Exposure depended on workload placement and block reassignment patterns. The researchers didn't demonstrate modification of active data or workload availability impact, limiting the potential damage scope.
8Security response timeline
Cloudflare addressed the vulnerability within hours of disclosure on September 4, 2026, completing initial fixes by September 7 and full cleanup by September 19. The rapid response included configuration changes, fleet-wide updates, and cache clearing. The company awarded a bug bounty and collaborated with researchers on public disclosure, maintaining transparency throughout the process.