Cloudflare Fixes Container Cross-Tenant Data Exposure Flaw
Cloudflare Fixes Cross-Tenant Data Leak in Container Service
Related Entities
Organizations
Products & Tech
Other
MITRE ATT&CK Techniques
Full Report
Executive Summary
Cloudflare has remediated a significant data exposure vulnerability in its Cloudflare Containers and Sandboxes services. The flaw, reported on September 4, 2026, by a security researcher, could have allowed a malicious tenant to read residual data left on disk by other tenants' containers that previously ran on the same physical host. This type of vulnerability is known as a cross-tenant data exposure. The root cause was a performance-optimization setting in the underlying storage system that disabled the zeroing of deallocated data blocks. Cloudflare conducted a thorough analysis of historical data and found no evidence that this vulnerability was maliciously exploited. The issue has been fixed by reverting to the default, more secure storage configuration.
Vulnerability Details
The vulnerability was not a traditional virtual machine escape but a subtle information leak at the storage layer. Cloudflare's container platform uses Linux device mapper thin provisioning (dm-thin) for storage allocation. For performance reasons on certain storage pools, the skip_block_zeroing option was enabled. This option instructs the kernel not to wipe a 64 KiB storage block with zeros before reallocating it to a new container.
The researcher, Oren Yomtov, discovered that by writing a small amount of data (e.g., 4 KiB) to a newly allocated block, they could then read the entire 64 KiB block. This block could contain up to 60 KiB of stale data from a previous container that had used that same physical storage block. This allowed the researcher to recover fragments of data from other tenants, including file system structures, database pages, and even complete SQLite databases. An attacker could not target a specific victim, as the data they could access depended entirely on the unpredictable workload placement and block reallocation by the hypervisor.
Affected Systems
- Cloudflare Containers: Customers on the Workers Paid plan using this service.
- Cloudflare Sandboxes: This service is built on the same underlying platform and was also affected.
The vulnerability only affected paying customers, as they had the necessary permissions to provision storage in the affected manner. Free-tier users were not impacted.
Exploitation Status
Cloudflare has stated that there is no evidence of malicious exploitation of this vulnerability in the wild. Their incident response team developed signatures to detect the specific exploitation pattern and scanned historical disk I/O telemetry. The only activity found matched the benign research conducted by the reporting security researcher. Cloudflare awarded a bug bounty for the responsible disclosure.
Impact Assessment
Had this vulnerability been exploited, it could have led to a serious breach of customer data confidentiality. In a multi-tenant cloud environment, strict separation between tenants is a fundamental security requirement. This flaw broke that isolation at the storage layer. An attacker could have potentially recovered sensitive information such as API keys, passwords, private source code, or customer data that was written to disk by another tenant's container. While an attacker could not specifically target another customer, a large-scale, persistent effort could have yielded a significant amount of sensitive data over time. The fact that it was discovered and fixed without evidence of abuse prevented a potentially major security incident.
Cyber Observables — Hunting Hints
For cloud providers or large-scale container platform operators, detecting this type of issue requires deep introspection of the storage layer:
otherdm-thin with skip_block_zeroing enabledlog_sourceDisk I/O telemetryfile_path/sys/module/dm_thin_pool/parameters/Detection Methods
Detecting exploitation of this specific vulnerability is extremely difficult without access to the cloud provider's low-level infrastructure telemetry. Cloudflare's detection method involved:
- Pattern Signature: Building a signature based on the researcher's proof-of-concept, which involved a specific sequence of small writes followed by large reads to the same block offset.
- Historical Telemetry Analysis: Applying this signature retroactively to terabytes of historical disk I/O logs from the container platform to search for matching patterns.
D3-SFA: System File Analysisat a massive scale.
For tenants of a cloud provider, this type of flaw is generally undetectable from within their container or VM.
Remediation Steps
The remediation was straightforward and implemented by Cloudflare's engineering team:
- Configuration Change: Cloudflare removed the
skip_block_zeroingoption from theirdm-thinstorage pool configurations. This reverted the system to its default, secure behavior of always zeroing out a block before it is re-provisioned to a new tenant. - Verification: The fix was verified by the reporting researcher, who confirmed that they could no longer read residual data after the change was deployed.
This incident serves as a crucial reminder that performance optimizations in complex systems can sometimes have unintended and severe security consequences. D3-PH: Platform Hardening
Timeline of Events
MITRE ATT&CK Mitigations
Operating System Configuration
Ensuring secure default configurations for OS and kernel-level features is critical. Disabling risky performance optimizations like 'skip_block_zeroing' is a key mitigation.
Mapped D3FEND Techniques:
Strong isolation between tenants at all layers of the stack (CPU, memory, network, storage) is fundamental to cloud security.
Mapped D3FEND Techniques:
D3FEND Defensive Countermeasures
This incident is a textbook case for the importance of Platform Hardening, specifically in the context of a cloud provider's infrastructure. The vulnerability in Cloudflare Containers was not an application bug but a platform-level configuration choice (skip_block_zeroing) that prioritized performance over security. The primary countermeasure is to establish and enforce a secure-by-default configuration baseline for all components of the platform, from the kernel upwards. Any deviation from this baseline, especially for performance optimization, must undergo a rigorous security review to analyze potential side effects. For platforms using Linux dm-thin, this means the default behavior of zeroing blocks must be maintained. This incident teaches that security cannot be an afterthought to performance; secure configurations must be the non-negotiable foundation of any multi-tenant service.
To proactively discover flaws like the one in Cloudflare Containers, platform providers should incorporate dynamic analysis and fuzzing that specifically targets multi-tenancy boundaries. Instead of just testing a single container's functionality, security testing should involve deploying multiple 'fuzzer' tenants onto the same host. These tenants would be programmed to write known data patterns to disk, deallocate the storage, and then have other tenants on the same host attempt to allocate new storage and read it to see if any of the known patterns 'leak' through. This form of 'cross-tenant fuzzing' can dynamically test the isolation guarantees of the underlying storage, memory, and network layers, helping to uncover subtle information disclosure bugs that static analysis or traditional penetration tests might miss.
Timeline of Events
Security researcher Oren Yomtov reports the vulnerability to Cloudflare.
Cloudflare awards a bounty to the researcher after confirming the fix is effective.
Cloudflare publicly discloses the vulnerability and remediation.
Sources & References
Article Author
Jason Gomes
• Cybersecurity PractitionerCybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Editorial Standards & Analyst Review
CyberNetSec.io uses automation to assist source monitoring, deduplication, observable extraction, and structured intelligence generation. Published analysis follows human-defined editorial standards and adds defensive context including MITRE ATT&CK, D3FEND, STIX, and Sigma where applicable. Read our editorial policy.
Tags
📢 Share This Article
Help others stay informed about cybersecurity threats
🎯 MITRE ATT&CK Mapped
Every tactic, technique, and sub-technique used in this threat has been identified and mapped to the MITRE ATT&CK framework for consistent, actionable threat language.
🧠 Enriched & Analyzed
Observables and indicators of compromise (IOCs) have been extracted and cataloged. Risk has been assessed and correlated with known threat actors and historical campaigns.
🛡️ Actionable Guidance
Detection rules, incident response steps, and D3FEND-aligned mitigation strategies are included so your team can act on this intelligence immediately.
🔗 STIX Visualizer
Structured threat data is packaged as a STIX 2.1 bundle and can be visualized as an interactive graph — relationships between actors, malware, techniques, and indicators.
⚡ Sigma Generator
Sigma detection rules are derived from the threat techniques in this article and can be converted for deployment across any major SIEM or EDR platform.