AiCybr

Cloudflare Containers Cross-Tenant Disk Exposure: What Was Affected and How It Was Fixed

By AiCybr Editorial · Published September 26, 2026

Cloudflare disclosed on September 24, 2026 that it had fully remediated a cross-tenant data-exposure vulnerability in Cloudflare Containers and Cloudflare Sandboxes. The flaw could allow a customer with a Workers Paid account to recover residual disk blocks previously used by another customer's workload on the same underlying host.

Cloudflare says its retained historical disk-I/O telemetry showed no evidence of malicious exploitation beyond the authorized research and validation activity. The researchers did recover residual material from other filesystems during controlled testing, including directory structures, database pages and structurally complete SQLite databases. The fleet-wide fix is complete and customers do not need to change configuration or take remediation action, according to Cloudflare.

The vulnerability was reported through Cloudflare's bug-bounty program on September 4 by Oren Yomtov of Accomplish. Cloudflare began deploying its primary mitigation the same day, completed that rollout on September 7, and finished cleanup of pre-mitigation cached snapshots across the affected fleet on September 19.

What was affected

Cloudflare says the issue affected Containers and Sandboxes, which is built on Containers. Containers run customer workloads on multi-tenant infrastructure inside dedicated Firecracker virtual machines.

Each container receives a writable root disk backed by Linux device-mapper thin provisioning (dm-thin). The affected storage pools used 64 KiB thin blocks and had the skip_block_zeroing option enabled.

When a container's thin volume was deleted, its physical blocks returned to a pool used by workloads from multiple customer accounts. With block zeroing skipped, a subsequently allocated block could retain bytes written by its previous owner in portions that the new workload had not overwritten.

That storage behavior created the cross-tenant exposure boundary: a newly placed workload could receive a previously used physical block and recover residual content from the unwritten portion.

What the researchers demonstrated

Cloudflare's joint disclosure with the researchers reports residual material on 18 of 24 production placements and 20 of 22 underlying nodes across four continents during controlled testing.

The researchers evaluated 5,614 testable directory blocks using ext4 directory-block checksums. None were attributed to their own test filesystem, while checksum analysis identified 2,700 distinct foreign directory inodes. A separate controlled validation correctly attributed all 162 deliberately created test blocks to the researchers' filesystem.

Cloudflare says the recovered block types included directory structures, database pages and structurally complete SQLite databases. The materials submitted to Cloudflare contained aggregate measurements and validation data rather than recovered third-party content values or identifiers, and the researchers subsequently confirmed deletion of recovered data under their control.

Exposure boundaries

The issue crossed Cloudflare's tenant-isolation boundary, with potential exposure of filesystem metadata, directory structures, database pages and application data from previously released blocks.

Several constraints limited targeting. Cloudflare automatically assigns workloads to eligible hosts, so an attacker could not select a particular victim, workload, host or data set. Residual content was also dependent on which released blocks were subsequently allocated. The demonstrated issue concerned released storage blocks; Cloudflare reports no demonstrated modification of another customer's active data or impact to workload availability.

Exploitation required access to the Containers platform through a Workers Paid account.

How Cloudflare fixed the storage flaw

Cloudflare's first mitigation removed skip_block_zeroing from the dm-thin pool configuration. That restores the default behavior of clearing newly allocated physical blocks before exposing them to a new container.

The company then addressed residual pre-mitigation state across the fleet. Its published timeline says it drained hosts, restarted virtual machines and cleared affected cached image state, with cleanup of all pre-mitigation cached snapshots completed September 19.

Cloudflare also built detection signatures around the relevant disk-I/O behavior and applied them to retained telemetry. It says attributable matches came from the researchers and Cloudflare engineers performing authorized validation, with no additional activity consistent with the reported exploitation technique in the telemetry available for review.

Remediation timeline

Date Event
September 4, 15:26 UTC Vulnerability reported through HackerOne
September 4, 18:45 UTC Cloudflare opened an incident and confirmed the production condition
September 4, 21:27 UTC Runtime fix and storage-reuse test merged
September 4, 23:15 UTC Fleet rollout began
September 7, 06:13 UTC Primary rollout completed; cleanup of old pool data began
September 14 Researchers confirmed their proof of concept had stopped working
September 19, 15:03 UTC Cleanup of pre-mitigation cached snapshots completed
September 24 Cloudflare published the coordinated disclosure

What Cloudflare customers need to do

Cloudflare states that the vulnerability has been patched across the affected fleet and requires no customer-side configuration change. Customers therefore do not have a vendor-prescribed patch, image upgrade or credential-rotation step for this incident.

Organizations with their own incident-response requirements can preserve Cloudflare's September 4–19 remediation timeline in internal risk records and evaluate whether workloads that used Containers or Sandboxes before remediation handled data requiring additional assurance review. Cloudflare's disclosure does not establish September 4 as the beginning of the vulnerable configuration, so that remediation timeline should not be treated as the full historical exposure window.

For operators of self-managed multi-tenant Linux infrastructure, the incident also provides a concrete storage-isolation lesson: thin-provisioned block reuse must clear data before blocks cross a tenant boundary. Isolation at the VM or container layer does not erase residual bytes in an underlying shared block pool.

Why the failure mattered despite Firecracker isolation

Cloudflare Containers place each workload inside a dedicated Firecracker microVM, providing a strong compute-isolation boundary. The disclosed failure occurred lower in the storage lifecycle: physical blocks returned to a shared dm-thin pool without being zeroed before reuse.

That distinction matters for cloud architecture because tenant isolation is a composition of controls across compute, memory, storage, networking and management planes. A correctly isolated virtual machine can still receive stale information when the backing storage allocator violates the same tenant boundary.

Cloudflare's remediation addresses that specific lifecycle by zeroing newly allocated blocks and clearing residual pre-fix state across the fleet.

Bottom line

Cloudflare's September disclosure documents a material multi-tenant storage-isolation failure in Containers and Sandboxes. Controlled testing recovered residual structures from previously used blocks across multiple production placements, while Cloudflare's retained telemetry found no additional activity consistent with the reported exploitation technique beyond authorized research and validation.

The primary mitigation was deployed beginning September 4, fleet cleanup finished September 19, and Cloudflare says customers have no remediation action to perform. The durable engineering lesson is broader: microVM isolation and storage sanitization are separate controls, and shared block pools must enforce tenant separation when physical capacity is recycled.

Sources

Continue reading

Security Microsoft Storm-2570: Hunt the Tradecraft Behind Qilin, DragonForce, Anubis and BERT

Microsoft says Storm-2570 reuses remote-management, credential-access, lateral-movement and exfiltration tools across four ransomware families. Here are the highest-value defender signals and controls.

AI OpenAI Adds API Key Expiration and Maximum-Lifetime Controls: Rotation Guide

OpenAI now lets teams set expiration dates on project API keys and enforce maximum key lifetimes at the organization or project level. This guide covers the new controls, service-account API limits and a safe production rotation workflow.

AI Google Cloud Agent Identity Auth Manager: OAuth, API Keys, and the New Credential Boundary for AI Agents

Google Cloud's Agent Identity auth manager gives deployed AI agents a managed way to use OAuth and API-key credentials. Here is what it changes, how the flow works, and what security teams should verify before adopting it.