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

Key facts

Detection coverage

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. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Credential-Bearing File Access Following Raw Block Device Read (Residual Data Harvesting) — SPL

Detects post-exploitation harvesting of credential-bearing artifacts recovered from residual dm-thin storage blocks: a process that opens a raw block device path and, within a short window, also opens a .env file, a SQLite database, or a Chromium profile artifact ("Login Data"/"Cookies"). Cloudflare's researcher recovered structurally complete SQLite databases, Chromium profile data, and .env files directly from unzeroed reused blocks belonging to other tenants.

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1552.001, T1555.003, T1213, T1119
• Data sources: linux_auditd (SYSCALL/PATH records), sysmon_for_linux (FileCreate/RawAccessRead), microsoft_defender_for_endpoint_linux (DeviceFileEvents)
• Severity: critical
• Confidence: medium

Splunk SPL

index=linux_audit sourcetype="auditd" (type=SYSCALL OR type=PATH)
| eval target=coalesce(name, path)
| eval event_class=case(
    match(target, "^/dev/(vd[a-z]+|dm-[0-9]+|mapper/.+)$"), "rawdev_access",
    match(target, "(?i)\.env$"), "credfile_env",
    match(target, "(?i)\.(sqlite|db)$"), "credfile_sqlite",
    match(target, "(?i)(Login Data|Cookies)$"), "credfile_browser",
    1=1, null())
| where isnotnull(event_class)
| bin _time span=2m
| stats values(event_class) as event_classes values(target) as targets earliest(_time) as first_ts latest(_time) as last_ts by _time, exe, pid, user
| where mvfind(event_classes,"rawdev_access")>=0 AND (mvfind(event_classes,"credfile_env")>=0 OR mvfind(event_classes,"credfile_sqlite")>=0 OR mvfind(event_classes,"credfile_browser")>=0)
| table first_ts last_ts exe pid user targets
| sort - last_ts

Microsoft KQL

let lookback = 24h;
let rawDevAccess = DeviceFileEvents
| where Timestamp > ago(lookback)
| where FolderPath matches regex @"^/dev/(vd[a-z]+|dm-\d+|mapper/.+)$"
| project Timestamp, DeviceId, Account = InitiatingProcessAccountName, InitiatingProcessId, Process = InitiatingProcessFileName, RawDevPath = FolderPath;
let credFileAccess = DeviceFileEvents
| where Timestamp > ago(lookback)
| where FileName has_any (".env", ".sqlite", ".db") or FileName in ("Login Data", "Cookies")
| project Timestamp, DeviceId, InitiatingProcessId, CredFile = FileName;
rawDevAccess
| join kind=inner (credFileAccess) on DeviceId, InitiatingProcessId
| where abs(datetime_diff('second', Timestamp, Timestamp1)) <= 120
| project FirstSeen = Timestamp, SecondSeen = Timestamp1, DeviceId, Account, Process, RawDevPath, CredFile
| order by SecondSeen desc

Sigma

title: Non-Standard Process Access to Credential-Bearing Files Consistent with Residual Disk-Block Harvesting
id: b1c4d7e0-2a5f-4c8b-9d1e-6f3a0b7c2d4e
status: experimental
description: Detects generic file-read/scripting utilities (cat, dd, python, hexdump, strings) opening credential-bearing artifacts (.env files, SQLite databases, or Chromium "Login Data"/"Cookies" profile files) outside their normal owning application context, consistent with harvesting residual data recovered via the Cloudflare Containers dm-thin skip_block_zeroing cross-tenant exposure.
references:
    - https://blog.cloudflare.com/containers-cross-tenant-vulnerability/
author: Threadlinqs Team
date: 2026-09-27
tags:
    - attack.credential_access
    - attack.t1552.001
    - attack.t1555.003
    - attack.collection
    - attack.t1213
    - attack.t1119
logsource:
    category: file_event
    product: linux
detection:
    sel_proc:
        Image|endswith:
            - '/cat'
            - '/dd'
            - '/python3'
            - '/python'
            - '/hexdump'
            - '/strings'
    sel_target:
        TargetFilename|endswith:
            - '.env'
            - '.sqlite'
            - '.db'
    sel_target_browser:
        TargetFilename|contains:
            - 'Login Data'
            - 'Cookies'
    condition: sel_proc and (sel_target or sel_target_browser)
falsepositives:
    - Application startup, backup, or CI/test tooling legitimately reading these files with a generic utility
    - Developers debugging locally with cat/hexdump against their own .env or SQLite files
level: medium

Known false positives:

• Backup, DLP-scanning, or CI/test pipelines that legitimately enumerate both raw devices and credential-style files in the same job
• Container image build systems reading .env/SQLite fixtures during automated tests

Tuning notes: Exclude known backup/DLP/CI service accounts and their scheduled job windows; require the rawdev_access target to match the environment's specific container-root-disk naming convention rather than any block device; extend the 2-minute correlation window only if the platform's own storage layer shows higher I/O latency.

• 🔒 Raw Block Device Small-Write-Then-Large-Read Fingerprint (dm-thin Residual Data Probe) — KQL · unlock with TL Creds
• 🔒 Credential-Bearing File Access Following Raw Block Device Read (Residual Data Harvesting) — KQL · unlock with TL Creds
• 🔒 Cross-Placement Container/Sandbox API Enumeration Indicative of Cross-Tenant Storage Probing — KQL · unlock with TL Creds
• 🔒 Raw Block Device Read Following Small Aligned Write (dm-thin Residual Data Probe) — Sigma · unlock with TL Creds
• 🔒 Non-Standard Process Access to Credential-Bearing Files Consistent with Residual Disk-Block Harvesting — Sigma · unlock with TL Creds
• 🔒 High-Volume Cross-Placement Container/Sandbox Enumeration via Cloud API (Cross-Tenant Storage Probing) — Sigma · unlock with TL Creds
• 🔒 Raw Block Device Small-Write-Then-Large-Read Fingerprint (dm-thin Residual Data Probe) — SPL · unlock with TL Creds
• 🔒 Cross-Placement Container/Sandbox API Enumeration Indicative of Cross-Tenant Storage Probing — SPL · unlock with TL Creds

Indicators of compromise

As of 2026-09-27, Threadlinqs Intelligence tracks 12 indicators of compromise for TL-2026-2698.

Technical analysis

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.

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 by tactic:

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

Remediation

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

Affected and fixed versions

• 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

Timeline

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

Sources cited

• How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers blog.cloudflare.com · Vendor report · 2026-09-19
• Thin provisioning — The Linux Kernel documentation (device-mapper dm-thin, skip_block_zeroing) kernel.org · Research · 2026-09-27
• Containers and Sandboxes are now generally available developers.cloudflare.com · Vendor report · 2026-04-13
• Cloudflare Containers Cross-Tenant Disk Exposure: What Was Affected and How It Was Fixed aicybr.com · Blog · 2026-09-26
• Cloudflare Containers Flaw Leaked Data on 18 Hosts shattered.io · Blog · 2026-09-26
• Cloudflare fixes Containers cross-tenant flaw exposing customer data BleepingComputer · News · 2026-09-27
• Cloudflare Containers Vulnerability Could Leak Data Between Customer Workloads cybersecuritynews.com · News · 2026-09-27
• Cloudflare Containers Flaw Could Expose Data From Other Customers' Workloads gbhackers.com · News · 2026-09-25
• Cloudflare Fixes Cross-Tenant Data Exposure Bug in Containers technadu.com · News · 2026-09-25

More in vulnerability

• Critical Zoom Workplace for Windows Flaws (CVE-2026-108186, CVE-2026-108187) Allow Unauthenticated Remote Privilege Escalation
• Windows SignDrop 0-Day: CLFS (clfs.sys) Local Privilege Escalation to SYSTEM with Public PoC (No CVE Assigned)
• Ivanti EPM SQLi RCE (CVE-2026-121653) and CSA Missing Authentication (CVE-2026-121683); Citrix XenServer and Ivanti Sentry/EPMM Patches
• Git Fixes 6 Vulnerabilities Enabling Code Execution via Cloned Repositories (CVE-2026-111760 et al.)
• CVE-2024-0244 – Unauthenticated Heap Buffer Overflow in Canon MF753Cdw Printer (Fax Job Handling, /wsd/print)

Previous and next in vulnerability

• Two Unpatched Citrix NetScaler Zero-Day RCE Vulnerabilities Under Active Exploitation Previous report
• Citrix Patches Two Actively Exploited NetScaler Zero-Days (CVE-2026-88771, CVE-2026-88772) Next report