Cloudflare Containers: Vulnerability Allowing Reading of Residual Data from Other Tenants via Reused Blocks

wpnews.pro

Article Title : How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers #

Publisher : Cloudflare #

Publication Date : 2026-09-24 #

Severity : High (A vulnerability that could break the cross-tenant confidentiality boundary. Targeting specific victims, modifying active disks, and causing denial of service were not confirmed, and Cloudflare has found no evidence of malicious exploitation.) #

Fix Details : Corrected the source title and distinguished authorized research on production infrastructure from malicious theft. Outlined the stages of successful information exposure, residual risks in existing allocations, and countermeasures taken by both Cloudflare and customers.

#

Quick Summary

In Cloudflare Containers and Sandboxes, portions of reused blocks left untouched by new writes could expose data fragments from other tenants because the blocks had not been zero-initialized. Cloudflare fixed the configuration and discarded existing disks and snapshots.

#

Attack Flow

Path to Read Unwritten Areas of Reused 64KiB Blocks

An attacker writes 4KiB of data to unallocated virtual disk space within their own Cloudflare Containers or Sandboxes environment.
dm-thin allocates a 64KiB block from the same physical pool that was previously used by another tenant. Because skip_block_zeroing was set, zeroing of the entire block was not performed.
Data fragments from the past remain in the remaining 60KiB other than the 4KiB written by the attacker. The attacker collects this fragment data by directly reading their own virtual block device (/dev/vdc ).
Block allocation can be repeated to collect fragments if residual data exists. However, residual data does not necessarily exist with every allocation, and specific target organizations, hosts, or data cannot be targeted.

#

Attacker Position and Execution Location

The attacker is a tenant who can run their own Containers or Sandboxes on Workers Paid. Authentication to other tenants is not required.
Reading is performed against the assigned virtual block device from within the attacker's own container. There are no reports of direct access to the host or running disks of other tenants.

#

Victim and Administrator Perspective

Victims

Victim containers and applications may not show any errors or screen changes.

Administrators

Standard logs on the victim tenant side may not directly capture the reading of residual blocks reassigned to another tenant. Notifications from Cloudflare, the usage period, and inventory of stored data are the primary confirmation methods.

#

Success and Failure Conditions

Success Conditions

The attacker creates a container in the target service, writes to unallocated virtual disk space, and can read raw blocks.
A block previously used by another tenant in the same physical pool is reused, and data remains in areas not overwritten by the attacker's write.
To gain useful information from fragments, the residual content must include sensitive information, and the fragments must be interpretable and re-constructible. Specific targets cannot be chosen.

Failure Conditions and Risk Mitigation

Cloudflare enabled zero-initialization for new block allocations in dm-thin. Customers do not need to change this infrastructure setting.
Because zero-initialization of new allocations does not erase existing allocations, Cloudflare also discarded and recreated pre-fix disks and cached snapshots. This is a remediation measure by the infrastructure operator.
Users should avoid placing plaintext long-term credentials in persistent or temporary storage, and use short-lived credentials and encryption to reduce the impact of exposure.

#

What Happens Upon Success

Storage fragments of another tenant may be assigned to the attacker, potentially compromising confidentiality.
Public reports do not indicate modification of actively connected victim disks, targeted attacks against specific tenants, or denial of service.
Cloudflare found no evidence of malicious exploitation in its retained telemetry. This does not rule out exploitation outside the retention period or beyond the available telemetry's coverage.

#

Observable Logs

Email : This is not an attack using email for initial intrusion. #

Proxy / SWG / DNS : Web and DNS logs on the victim tenant side may not show this physical block reuse. #

Endpoint / EDR : Raw block reading may appear as an in-container operation on the attacker side, but is generally unobservable from the victim side EDR. #

Identity / IdP : Review potentially exposed credentials for suspicious use during and after the potential exposure period, including after September 19. Such activity is not direct evidence of residual-block reads. #

SaaS / Cloud : Cloudflare management records, notifications, container creation, and internal telemetry of disk lifecycles are primary sources of information. Logs visible to customers are limited. #

Network : If the attacker transmits collected data externally, it appears in the communication on the attacker tenant side. It cannot be confirmed by the victim tenant's communication logs alone.

#

Attack Success Determination

Information exposure confirmed in authorized research : Public Info: A researcher recovered residual blocks originating from other tenants reassigned to their own container on production infrastructure. What was confirmed was information exposure in authorized research, not malicious theft or session compromise. (Target: Authorized researcher verification on production infrastructure. Cloudflare also reproduced the issue) #

Attack attempt observed (success unconfirmed) : Criteria: Massive disk allocations or raw block reads alone do not confirm the acquisition of useful data from another tenant. (Target: Cloudflare internal telemetry) #

Criteria for confirming customer data exposure : Criteria: The recovered fragments contain identifiable information of the organization, supported by distribution and acquisition on the attacker side. Cloudflare has not confirmed evidence of malicious exploitation. (Target: Individual customer impact confirmation)

#

Investigation Playbook

Starting Point : Start with notifications from Cloudflare, use of the target service prior to September 19, and unauthorized use of suspected exposed secrets. #

Initial Check : Inventory the usage period, purpose, stored data, credentials, and encryption status of Containers and Sandboxes. #

Endpoint and Server Investigation : Because this is not a compromise of customer hosts, do not draw conclusions from endpoint investigations alone. Identify data and images placed in the target container. #

Authentication and Cloud Investigation : Check the usage history of API keys, tokens, and connection strings that may have been stored, and rotate them as necessary. #

Tracing Subsequent Operations : Track unauthorized access to clouds, SaaS, and databases using potentially leaked credentials. #

Containment : Confirm the completion of Cloudflare's fix, rotate potentially exposed secrets based on impact assessment, and determine the necessity of regulatory and contractual notifications. #

Decision Categories : Record separately the infrastructure vulnerability, fragment read possibility, acquisition of sensitive information, and abuse of credentials.

#

Defense and Detection Ideas

Single Event : Because customers can hardly obtain a definitive single event, vendor notifications and suspicious use of credentials should be emphasized. #

Time-Series Correlation : Correlate the usage period of the target service, stored data, and suspicious credential use in a time series. #

Threat Hunting : Inventory plaintext secrets and persistent data handled in containers and sandboxes prior to September 19. #

Log Limitations : Cross-tenant physical block reuse is likely invisible in victim tenant standard logs, and the absence of exploitation cannot be proven by customers alone. #

Priority Measures : Customers should check the vendor's remediation status and stored data, and consider short-lived secrets and encryption. Zero-initialization and discarding existing disks/snapshots are measures for the infrastructure operator.

#

Facts / Inference / Hypothesis

Facts

Oren Yomtov of Accomplish reported on September 4, 2026, a problem where residual data of other tenants could be read in Cloudflare Containers and Sandboxes.
Cloudflare placed multi-tenant disks in the same dm-thin physical pool and omitted zero-initialization of 64KiB blocks via skip_block_zeroing .
When a new container wrote 4KiB to unallocated space, the remaining 60KiB of the reused 64KiB block was not overwritten, and direct reading of /dev/vdc could expose fragments of the previous tenant.
The researcher recovered residual blocks originating from other tenants in production infrastructure deployments and verified via checksums that they did not originate from their own file system. Cloudflare found no evidence of exploitation beyond authorized validation within the historical telemetry available to it.
The researcher could not target specific victims, hosts, or data, and showed no impact on the read/write or availability of actively connected disks.
Cloudflare removed skip_block_zeroing , phased out active existing disks, deleted cached snapshots, and completed remediation by September 19.
Cloudflare confirmed no evidence of malicious exploitation in the telemetry it retained and stated that customer-side actions are unnecessary.

Inference

If residual blocks contained sensitive information, application data, database fragments, directory structures, etc., could leak across tenants. A distinction must be made between the existence of fragments and the success of content reconstruction.
When performing performance optimization on shared storage, zero-initialization guarantees during physical block reuse must be treated as tenant boundaries, not just logical volume creation.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "14. Unknowns and Additional Investigation".

#

MITRE ATT&CK Mapping

#

Unknowns and Additional Investigation

Whether malicious actors utilized this path beyond the verification by researchers and Cloudflare.
The full scope of customers and data types that could have been exposed.
The possibility of exploitation existing in telemetry outside the retention period.

#

Impact on SOCs and Organizations

Cloudflare has remediated the vulnerability in Containers and Sandboxes; customers do not need to make infrastructure configuration changes. However, if sensitive data was temporarily stored before September 19, check vendor notifications and the scope of internal usage, and perform secret rotation and legal/privacy evaluations as necessary. Even in general container infrastructures, it is worth confirming whether zero-initialization is guaranteed during block reuse in thin provisioning.

#

Summary by Target Audience

For SOCs : Assuming the completion of Cloudflare's fixes, check usage scope before September 19, sensitive data, and vendor notifications. Standard customer logs alone may not determine the reading of fragments from other tenants. #

For Administrators : No customer-side fix operations are required. Identify the purposes for which sensitive information was stored, and rotate credentials as necessary. Verify erasure during block reuse on internal infrastructure. #

For Users : This is an issue on the cloud infrastructure side that does not require actions from general users, and Cloudflare has fixed it.

source & further reading

dev.to — original article Agent history is unsigned and writable by anyone Three things that broke when I moved AI image models into the browser Bridging the Knowledge Gap: Why General LLMs Fail at HEOR and How to Fix it with RAG 🏥🤖