# Cloudflare Containers cross-tenant residual disk data exposure via device-mapper thin-provisioning skip_block_zeroing

> A cross-tenant data exposure in Cloudflare's Containers platform (and Sandboxes, built on it) let one customer's workload recover residual disk bytes left by another tenant on the same physical host. The flaw lived in the storage layer — Linux device-mapper thin provisioning with skip_block_zeroing — not a conventional container or VM escape. Disclosed via HackerOne on 2026-09-04 by Oren Yomtov of Accomplish; Cloudflare found no evidence of malicious exploitation and remediated the fleet by 2026-09-07. No CVE or CVSS was assigned.

- **Published:** 2026-09-24T00:00:00Z
- **Last reviewed:** 2026-09-24T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2644
- **ID:** TL-2026-2644
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 · **IOCs:** 12 (full data via the Threadlinqs MCP server — Purple tier)

## Description

On 2026-09-04, security researcher Oren Yomtov of Accomplish responsibly reported a cross-tenant data exposure vulnerability in Cloudflare Containers through Cloudflare's HackerOne bug-bounty program (report #3997565). Cloudflare Containers runs each customer workload inside a dedicated Firecracker microVM whose writable root disk is exposed to the guest as /dev/vdc. That disk is backed by Linux device-mapper thin provisioning (dm-thin), which allocates physical storage from a shared pool in 64 KiB blocks, allocating a block only on first write to an unmapped region. The affected storage pools had the dm-thin pool option skip_block_zeroing configured, which caused the block layer to skip clearing (zeroing) a newly allocated block before exposing it. When a previous container's disk was deleted, its physical blocks were returned to the shared pool without being sanitized, and a later tenant on the same host could be handed a block still holding the prior owner's bytes. This crossed the tenant-isolation boundary at the storage layer rather than via a conventional container or VM escape.

The exploit technique is precise and storage-specific. The attacker, holding a legitimate Workers Paid account, created a container and opened /dev/vdc as a raw block device. The proof of concept read a baseline of the disk, then identified 64 KiB-aligned regions corresponding to free space in the guest's ext4 filesystem and wrote a single aligned 4 KiB block into each region. That write forced dm-thin to allocate a physical 64 KiB block from the shared pool (the pool serves workloads from multiple customer accounts). Because zeroing was disabled, the 4 KiB write overwrote only that portion, leaving the remaining ~60 KiB of the block intact — potentially residual data from a previous tenant's container. A subsequent raw-device read of /dev/vdc then exposed those bytes. Notably, reading an unmapped region before writing returned zeroes (dm-thin returns zeroes without allocating), so the trigger write was the required step to force allocation. An automated scanning workflow (the researchers' scripts) drove the write/read cycle across the disk.

The researchers validated the finding across six production placements using ext4 metadata_csum directory-block checksums to attribute blocks to filesystems and inodes. Of 5,614 testable directory blocks examined, none belonged to the researchers' own proof-of-concept filesystem (a control of 162 deliberately created/deleted blocks was all correctly attributed), and 2,700 distinct foreign directory inodes were identified. Residual material appeared on 18 of 24 placements and 20 of 22 underlying nodes across four continents. Recovered block types included directory structures, database pages, and structurally complete SQLite databases. The researchers submitted only aggregate counts and format checks — no third-party filenames, identifiers, credentials, hostnames, addresses, or content values — and confirmed the recovered data was securely deleted after submission.

Exploitation was opportunistic rather than targeted: the attacker could not choose a victim, workload, host, or specific information, and residual data was not guaranteed to be present. There was no access to actively attached disks, no ability to modify another customer's live data, and no impact on workload availability. Cloudflare reviewed retained historical disk-I/O telemetry and found no evidence of malicious exploitation or customer-data compromise — only activity attributable to the Accomplish researchers and Cloudflare's own authorized validation.

Cloudflare remediated the fleet by removing skip_block_zeroing from the affected dm-thin pool configuration across the fleet, restoring dm-thin's default behavior of clearing newly allocated blocks. Because zeroing new allocations did not sanitize already-mapped blocks (and new containers could inherit mappings from cached OCI image layer snapshots without re-allocating), Cloudflare also retired running container disks, drained hosts during off-peak hours, restarted VMs, and cleared image caches so disks and cached layers were recreated with zeroed allocations. Runtime fix was merged the same day (2026-09-04), the fleet-wide rollout completed 2026-09-07, old pool data clearing began, the researchers confirmed the PoC no longer worked on 2026-09-14, and all pre-mitigation cached snapshots were cleaned up by 2026-09-19. Cloudflare also built detection signatures around the attack's characteristic I/O pattern — a small 4 KiB write triggering allocation of a reused 64 KiB block, followed by reads recovering substantially more data than was written — and applied them to historical disk-I/O telemetry.

No CVE identifier or CVSS score was assigned. Oren Yomtov reported a $200,000 bounty (per his public LinkedIn post, awarded as cloud-service credits). Affected products are Cloudflare Containers (primary) and Cloudflare Sandboxes (built on Containers). No customer-side configuration change was required for remediation; Cloudflare notes organizations may consider precautionary rotation of secrets or customer data per their own risk policies.

## MITRE ATT&CK

- T1585.003 Cloud Accounts
- T1587 Develop Capabilities
- T1078.004 Cloud Accounts
- T1610 Deploy Container
- T1059.006 Python
- T1006 Direct Volume Access
- T1082 System Information Discovery
- T1613 Container and Resource Discovery
- T1005 Data from Local System
- T1048 Exfiltration Over Alternative Protocol

## Sources

- [How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers](https://blog.cloudflare.com/containers-cross-tenant-vulnerability/)
- [Cloudflare Containers Vulnerability (Cybersecurity News)](https://cybersecuritynews.com/cloudflare-containers-vulnerability/)
- [Cloudflare Containers Flaw Exposed Cross-Tenant Disk Data (Cyber Kendra)](https://www.cyberkendra.com/2026/09/cloudflare-containers-cross-tenant-disk-data-flaw.html)
- [How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (ChuckysCarnage repost)](https://chuckyscarnage.tech.blog/2026/09/24/how-cloudflare-addressed-a-cross-tenant-data-exposure-vulnerability-in-container/)
- [Oren Yomtov LinkedIn post (bounty disclosure)](https://www.linkedin.com/posts/orenyomtov_%D7%96%D7%9B%D7%99%D7%AA%D7%99-%D7%90%D7%AA%D7%9E%D7%95%D7%9C-%D7%91%D7%91%D7%90%D7%95%D7%A0%D7%98%D7%99-%D7%A9%D7%9C-200-%D7%90%D7%9C%D7%A3-%D7%93%D7%95%D7%9C%D7%A8-%D7%A9%D7%9C-%D7%91%D7%A2%D7%96%D7%A8%D7%AA-activity-7496489542926036993-P2-m)
- [Cloudflare Sandbox security model documentation](https://developers.cloudflare.com/sandbox/concepts/security/index.md)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2644