Cloudflare Containers residual data

Cloudflare fixed a vulnerability in its Containers service that allowed Workers Paid account holders to recover residual data from other customers’ containers on the same physical host. The flaw 2026, stemmed from a storage pool configuration that skipped zeroing reused memory blocks.

A security researcher showed that writing only 4 KiB to a reused 64 KiB block left 60 KiB of prior customer data intact due to disabled block zeroing. Cloudflare Containers use Linux device mapper thin provisioning to provide each container with a writable root disk. The affected storage pools used a 64 KiB thin-block size and included the option skip_block_zeroing. With this configured, dm-thin skips zeroing newly allocated blocks before making them accessible.

When the thin volume backing a container's root disk was deleted, its physical blocks were returned to a pool serving workloads from multiple customer accounts. By writing only 4 KiB to an unused region of a new container’s disk, researchers caused a reused 64 KiB physical block to be allocated. Without zeroing, only the 4 KiB write overwrote the block, leaving 60 KiB of residual data from a previous customer in a readable state.

The proof of concept identified 64 KiB-aligned regions corresponding to free space in the guest’s ext4 filesystem and wrote one aligned 4 KiB block into each region. When such a write reached an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. A subsequent raw-device read could therefore observe bytes that the new container had never written. Reading an unmapped region of a new thin disk did not reveal residual data. For an unmapped region, dm-thin returned zeroes without allocating a physical block.

Researchers found widespread residual data across global infrastructure

Testing revealed residual data including directory structures and SQLite databases on 20 of 22 servers across four continents. The researchers ultimately observed residual material on 18 of 24 placements and 20 of 22 underlying nodes. The recovered block types included directory structures, database pages, and structurally complete SQLite databases.

Exploiting the flaw would let an attacker read other customers' files, including directory listings, SQLite databases, Chromium profiles.env files, and credential files. Cloudflare stated a successful exploitation would have crossed the tenant-isolation boundary. The company said: "A successful exploitation would have crossed the tenant-isolation boundary and could disclose filesystem metadata, directory structures, database pages, and application data." The technique could not target a particular customer, workload, host, or data. An attacker would not have control over the victim or host, nor be able to read an actively attached disk.

Cloudflare confirmed and fixed the issue with no customer action needed

Cloudflare verified the flaw let one Workers Paid customer access another’s data, then remediated it by re-enabling zeroing and clearing old storage. The company confirmed a flaw in its Containers platform let one paying customer read data left behind by a different customer’s earlier workload. Cloudflare Sandboxes, a separate product, also used the same container infrastructure and was affected.

After examining logs, telemetry, and historical data, Cloudflare found no evidence that customer data was exposed via the method described. Customers need to take no action to address the risk. Cloudflare said researchers only used scripts that performed checks and returned aggregate counts, not actual disk contents, so no real customer data was exposed in the evaluation. Researchers did not demonstrate any way to change another customer’s data or disrupt their workloads.

The company removed the setting that caused skipped block zeroing. It retired existing container disks and cleared cached snapshots that may contain old mappings. Cloudflare applied the fixes to its infrastructure automatically and has fully remediated the vulnerability. Cloudflare applied a fix across the Containers fleet with no customer-side configuration changes required. Within historical disk-I/O telemetry, Cloudflare identified no evidence of malicious exploitation. Activity attributable to the reported technique came from researchers and Cloudflare engineers conducting authorized validation.

Bug was reported via bounty program and responsibly disclosed

Oren Yomtov, a security researcher at technology company Accomplish, reported the flaw. The bug was reported through Cloudflare’s bug bounty program on HackerOne on September 4, 2026, at 15:26 UTC. The submission included counts, block offsets, sizes, checksum results, and truncated hash prefixes. The materials provided to Cloudflare contained no third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values.

The researchers confirmed they securely deleted the recovered data. They used ext4 directory block checksums to distinguish blocks belonging to their own test filesystem from blocks originating from other filesystems. When ext4 uses the metadata_csum feature, directory block checksums incorporate values associated with the filesystem and inode. Residual data was not guaranteed to be present.

Each container lives inside a dedicated virtual machine powered by the Firecracker virtual machine monitor. Firecracker presents the disk to the virtual machine as /dev/vdc. Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region. Cloudflare completed all mitigation actions by September 19, 2026, including retiring old container disks and clearing cached snapshots.