Cloudflare says it has fully remediated a cross-tenant data exposure vulnerability in Cloudflare Containers after a responsible disclosure from security researcher Oren Yomtov of Accomplish. The company says it found no evidence that customer data was compromised, and that the issue was fixed across the fleet without requiring any action from customers.
What the Cloudflare Containers issue involved
The vulnerability affected Cloudflare Containers and Cloudflare Sandboxes, which are built on top of Containers. In a post published by Cloudflare, the company explained that its container workload system runs on multi-tenant infrastructure, where customers are not able to choose the underlying host machine.
According to Cloudflare, the researchers showed that a customer with a Workers Paid account could recover residual disk blocks that had previously been used by Containers on the same host. The company stressed that the technique could not target a specific customer, workload, host, or dataset, and that residual data was not guaranteed to be present.
How the storage behavior created risk
Cloudflare said the issue stemmed from how storage was configured for the affected pools. Containers used Linux device mapper thin provisioning, or dm-thin, to provide each container with a writable root disk, and each container ran inside a dedicated Firecracker virtual machine. Firecracker exposed the disk to the virtual machine as /dev/vdc.
The affected storage pools used a 64 KiB thin-block size and had skip_block_zeroing enabled. That setting meant dm-thin did not clear newly allocated blocks before making them available. If a reused 64 KiB block was reassigned, a full-block write would overwrite the whole block, but a smaller write could leave old data in the untouched portion.
How the vulnerability could be exercised
Cloudflare said the proof of concept did not reveal residual data by simply reading an unmapped region of a new thin disk, because dm-thin returned zeroes for unmapped space. Instead, the researchers identified 64 KiB-aligned regions that corresponded to free space in the guest’s ext4 filesystem and wrote a 4 KiB block into each one.
When that write hit an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. Because block zeroing was disabled, the 4 KiB write only changed part of the block. A later raw-device read could then expose bytes the new container had never written.
What the researchers reported
Cloudflare said the submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes, but no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values. The company also said the researchers securely deleted the recovered data after submission.
To validate the approach, the researchers used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem from blocks originating from other filesystems. Cloudflare said the researchers reported:
- All 5,614 testable directory blocks across six production placements
- Zero blocks attributed to the researchers’ filesystem
- 2,700 distinct foreign directory inodes identified through checksum analysis
Cloudflare said the researchers also tested the method on 162 blocks they had deliberately created and deleted in a controlled filesystem, and the attribution method correctly matched all of them. Across the production placements, the researchers reported residual material on 18 of 24 placements and 20 of 22 underlying nodes across four continents.
Potential impact and limits
Cloudflare said the vulnerability could have allowed a customer with a Workers Paid account to recover residual data from storage blocks previously used by other customers’ Containers on the same host. That could have exposed filesystem metadata, directory structures, database pages, and application data.
At the same time, the company said the attack had important limits. An attacker could not choose a specific victim or access an actively attached disk, and exposure depended on workload placement and which released blocks dm-thin reassigned. Cloudflare also said the researchers did not demonstrate modification of another customer’s active data or any impact on availability.
How Cloudflare mitigated the problem
Cloudflare said its first step was to remove skip_block_zeroing from the dm-thin pool configuration across the fleet. That restored the default behavior of clearing newly allocated blocks before they were exposed to a container. The researchers independently confirmed that their proof of concept stopped working after the change.
Because zeroing new allocations did not sanitize blocks already mapped into existing thin devices, Cloudflare also retired all running container disks and removed cached image snapshots created before the mitigation. The company said it drained hosts during off-peak hours, restarted the virtual machines on each host, and cleared each host’s image cache so disks and cached layers would be recreated using zeroed allocations.
Cloudflare said it completed that cleanup across the Containers fleet, with no customer-side configuration changes required.
No evidence of exploitation
Cloudflare said it reviewed historical disk I/O telemetry for signs of the reported technique. Using the proof of concept and internal reproduction as references, the company developed detection signatures and applied them to the data it had retained.
The company said it found activity attributable to the researchers and Cloudflare engineers conducting authorized validation, but no additional activity consistent with the exploit. In Cloudflare’s words, it saw no evidence that the attack vector was exploited by anyone else.
Timeline of the response
Cloudflare included a detailed timeline in its disclosure. The company said Oren Yomtov reported the issue through HackerOne on September 4 at 15:26 UTC. Cloudflare opened a security incident at 18:45 UTC, merged the runtime fix and reuse test at 21:27 UTC, merged changes for new and live pools at 22:03 UTC, and began rolling out the changes at 23:15 UTC.
Cloudflare said rollout was completed on September 7 at 06:13 UTC, researchers confirmed on September 14 at 10:50 UTC that the proof of concept had stopped working, the bounty was awarded at 12:52 UTC that day, and cleanup of all pre-mitigation cached snapshots across the affected fleet was completed on September 19 at 15:03 UTC.
Cloudflare Containers users are protected
Cloudflare says the vulnerability has been patched and that no further action is needed from customers. The company framed the incident as a reminder of the security challenges in multi-tenant systems and thanked the researchers for the responsible disclosure and collaboration.
For users of Cloudflare Containers and Cloudflare Sandboxes, the key takeaway is that the reported flaw has been addressed, the affected fleet has been cleaned up, and Cloudflare says it found no evidence of malicious abuse or customer data compromise.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cybersecurity Tech News
Last Modified: September 25, 2026 at 10:34 pm
2 views
