Cloudflare Containers Cross-Tenant Data Exposure via Unzeroed Reused Storage Blocks (skip_block_zeroing)

Cloudflare Containers Cross-Tenant Data Exposure via (TL-2026-2698) is a high-severity software vulnerability, first published 2026-09-27. It has no confirmed attribution, affects Cloudflare Cloudflare Containers, maps to 11 MITRE ATT&CK techniques (T1005, T1059, T1078.004), and is covered by 9 detection rules and 12 indicators of compromise.

Key facts for TL-2026-2698

Threat ID
TL-2026-2698
Severity
HIGH
Status
PATCHED
Category
VULNERABILITY
First published
2026-09-27
Last reviewed
2026-09-27
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
technology, cloud computing, software development, saas
Target regions
Global
Detection rules
9
Indicators of compromise
12

A cross-tenant data exposure flaw in Cloudflare Containers and Sandboxes (Workers Paid plan) let one customer recover residual disk data left behind by a different tenant's deleted container, because the shared dm-thin storage pool was configured with skip_block_zeroing and skipped clearing reused 64 KiB blocks. Security researcher Oren Yomtov of Accomplish responsibly disclosed the issue via HackerOne on September 4, 2026; Cloudflare merged a runtime fix within six hours, awarded the bounty within ten days, and completed fleet-wide remediation by September 19, 2026, finding no evidence of exploitation by anyone other than the reporting researcher and Cloudflare's own validation.

How Cloudflare Containers Cross-Tenant Data Exposure via works

Cloudflare Containers and the Sandbox SDK built on top of them run each customer workload in a dedicated Firecracker microVM whose root disk is presented to the guest as a writable block device (/dev/vdc). Storage for these disks is provisioned from shared pools using Linux device-mapper thin provisioning (dm-thin) with a 64 KiB thin-block size, which normally zeroes a newly allocated block before exposing it to a tenant. Cloudflare's pools were configured with the dm-thin feature argument skip_block_zeroing, which per the kernel's own documentation "skips zeroing newly allocated blocks before making them accessible" -- a setting chosen for allocation-latency performance that instead created a cross-tenant exposure.

Because thin-provisioned blocks are allocated in 64 KiB units while filesystem writes can be much smaller, a 4 KiB write into a previously unmapped, 64 KiB-aligned free region of an ext4 filesystem was enough to trigger dm-thin to hand back a physical block that a prior tenant's deleted container had used -- physical blocks return to the shared pool, serving multiple customer accounts, once a thin volume is deleted. Only the 4 KiB actually written was overwritten; the remaining 60 KiB of the block could still contain that prior tenant's bytes. A subsequent raw read of the underlying block device recovered this residual data without needing to target any specific customer or workload -- any Workers Paid account with Containers/Sandboxes access could probe for it, though Cloudflare's automatic, randomized workload placement meant an attacker could not choose a victim, host, workload, or specific piece of information in advance.

Researcher Oren Yomtov (Accomplish) validated the technique across production placements on four continents: of 24 container placements tested across 22 underlying nodes, 18 placements on 20 nodes returned residual foreign material, including directory structures and ext4 metadata (identifiable via the filesystem's metadata_csum directory-block checksums), database pages, structurally complete SQLite databases, Chromium browser profile data, .env files, and other credential-bearing files. Across a subset of six production placements the researcher's tooling examined 5,614 testable directory blocks and identified 2,700 distinct foreign directory inodes; per Cloudflare, the validation scripts only returned aggregate counts rather than exfiltrating actual file contents, and any recovered data was securely deleted after submission consistent with Cloudflare's HackerOne disclosure policy. A separate control set of 162 deliberately-created test blocks was later used to confirm the corrected dm-thin behavior actually zeroed new allocations post-fix.

Cloudflare additionally confirmed that its Browser Rendering product's Browser Run service shared the same affected dm-thin storage pools. Cloudflare's response timeline was compressed: the report landed at 15:26 UTC on September 4, the production flaw was confirmed at 18:45 UTC, a runtime fix removing skip_block_zeroing was merged at 21:27 UTC, an accompanying pool-configuration change merged at 22:03 UTC, and fleet-wide rollout began at 23:15 UTC the same day -- all within roughly eight hours of the initial report. Rollout completed September 7 at 06:13 UTC, after which Cloudflare began clearing pre-mitigation data: retiring and recreating all running container root disks that predated the fix (forcing zeroed allocation going forward), deleting cached OCI image-layer snapshots created before the change, and draining affected hosts during off-peak windows to restart VMs and clear image caches. The researcher's proof-of-concept was confirmed non-functional against the patched fleet on September 14 at 10:50 UTC, and the HackerOne bounty was awarded roughly two hours later at 12:52 UTC. All pre-mitigation disk and image-layer snapshots were removed fleet-wide by September 19 at 15:03 UTC, completing full remediation. As a defensive follow-up, Cloudflare also built detection signatures around the attack's distinctive disk-I/O fingerprint -- a small (~4 KiB) write immediately followed by a disproportionately large raw read from a newly allocated 64 KiB block -- and reviewed historical disk-I/O telemetry fleet-wide, attributing all anomalous access patterns solely to the reporting researcher and Cloudflare's own authorized validation. Cloudflare concluded there is no evidence any other party exploited the flaw or that customer data was compromised. No CVE has been assigned and Cloudflare did not publish a CVSS score; this is a storage-layer data-remanence bug, not a container, hypervisor, or Firecracker VM escape.

MITRE ATT&CK techniques used in TL-2026-2698

Collection

T1005 Data from Local System; T1119 Automated Collection; T1213 Data from Information Repositories

Execution

T1059 Command and Scripting Interpreter

Initial Access

T1078.004 Valid Accounts: Cloud Accounts

Discovery

T1082 System Information Discovery; T1580 Cloud Infrastructure Discovery

Credential Access

T1552.001 Credentials In Files; T1555.003 Credentials from Web Browsers

Resource Development

T1587.004 Develop Capabilities: Exploits

Reconnaissance

T1595.002 Vulnerability Scanning

Affected products and versions in Cloudflare Containers Cross-Tenant Data Exposure via

  • Cloudflare — Cloudflare Containers
    Vulnerable versions: all Workers Paid plan container deployments prior to the 2026-09-04 21:27 UTC runtime fix
    Fixed in: fleet-wide remediation completed 2026-09-19
  • Cloudflare — Cloudflare Sandboxes (Sandbox SDK)
    Vulnerable versions: all Sandbox deployments built on Cloudflare Containers prior to the fix
    Fixed in: fleet-wide remediation completed 2026-09-19
  • Cloudflare — Cloudflare Browser Rendering (Browser Run service)
    Vulnerable versions: deployments sharing the affected dm-thin storage pools prior to the fix
    Fixed in: fleet-wide remediation completed 2026-09-19

Remediation for Cloudflare Containers Cross-Tenant Data Exposure via

Patches

  • Disabled the skip_block_zeroing feature argument on all dm-thin storage pools backing Containers, Sandboxes, and the Browser Rendering Browser Run service, restoring default zero-on-allocation behavior for newly provisioned blocks

Immediate actions

  • Cloudflare confirmed the production flaw at 18:45 UTC on 2026-09-04, roughly three hours after the HackerOne report
  • Cloudflare merged a runtime fix removing skip_block_zeroing from the dm-thin pool configuration at 21:27 UTC on 2026-09-04, roughly six hours after the report
  • An accompanying dm-thin pool-configuration change merged at 22:03 UTC the same day, with fleet-wide rollout beginning at 23:15 UTC
  • Fleet-wide rollout of the fix and start of pre-mitigation data clearing completed 2026-09-07 06:13 UTC
  • Drained affected hosts during off-peak hours, restarted VMs, and cleared cached image layers as part of rollout

Workarounds

  • None required or available on the customer side; the fix was applied entirely server-side by Cloudflare and no customer action was necessary

Longer-term hardening

  • Retired and recreated all running container root disks that were created before the mitigation, forcing zeroed allocation going forward
  • Deleted all cached OCI image layer snapshots pre-dating the configuration change
  • Removed all pre-mitigation disk snapshots fleet-wide, completed 2026-09-19 15:03 UTC
  • Validated corrected zero-on-allocation behavior using a control set of 162 deliberately-created test blocks
  • Deployed detection signatures for the attack's disk-I/O fingerprint (a small ~4 KiB write immediately followed by a disproportionately large raw read from a newly-allocated 64 KiB block)
  • Reviewed historical disk-I/O telemetry fleet-wide to confirm no exploitation beyond the reporting researcher and internal validation

Weaknesses (CWE) in Cloudflare Containers Cross-Tenant Data Exposure via

CWE-226, CWE-668, CWE-200

Timeline of Cloudflare Containers Cross-Tenant Data Exposure via

  • Cloudflare Containers and Sandboxes reach general availability on the Workers Paid plan, later found to share the vulnerable dm-thin storage configuration.
  • Fleet-wide rollout of the fix begins at 23:15 UTC, roughly eight hours after the initial report.
  • An accompanying dm-thin storage-pool configuration change merges at 22:03 UTC.
  • Cloudflare merges a runtime fix removing skip_block_zeroing from the dm-thin pool configuration at 21:27 UTC, roughly six hours after the report.
  • Cloudflare confirms the flaw exists in production at 18:45 UTC, roughly three hours after the report.
  • Security researcher Oren Yomtov of Accomplish submits the cross-tenant data exposure finding to Cloudflare via HackerOne at 15:26 UTC.
  • Fleet-wide rollout of the fix completes at 06:13 UTC and Cloudflare begins clearing pre-mitigation data.
  • Cloudflare awards the HackerOne bounty to Oren Yomtov at 12:52 UTC, roughly two hours after confirming the PoC was neutralized.
  • Cloudflare confirms at 10:50 UTC that the researcher's proof-of-concept no longer functions against the patched fleet.
  • Cloudflare publishes its blog post detailing the vulnerability, root cause, scope, and remediation timeline.
  • All pre-mitigation disk and image-layer snapshots are removed fleet-wide at 15:03 UTC, completing full remediation.
  • Trade-press outlets including GBHackers and Technadu publish first coverage of Cloudflare's disclosure.
  • BleepingComputer and other mainstream security outlets publish coverage, bringing the issue to broader public attention.

Sources cited for Cloudflare Containers Cross-Tenant Data Exposure via

More in vulnerability

Detection coverage for TL-2026-2698

As of 2026-09-27, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-2698 across Splunk SPL, Microsoft KQL and Sigma, covering 12 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats