Cloudflare Containers and the higher-level products built on it — Cloudflare Sandboxes (an SDK that runs each sandbox in its own VM for strong isolation) and Cloudflare Browser Run — provide multi-tenant compute in which each customer workload runs in a Firecracker microVM with a writable root disk presented to the guest as /dev/vdc. That root disk is backed by a Linux device-mapper thin-provisioning (dm-thin) pool using a 64 KiB thin-block size. The affected storage pools were configured with the skip_block_zeroing option, which instructs the kernel to skip zeroing newly allocated blocks before they become accessible. Under normal thin provisioning the kernel zeroes a block on first mapping so a tenant can never observe another tenant's prior data; skip_block_zeroing disabled that guarantee.

The result was a cross-tenant residual-data disclosure. When a container's thin volume was deleted, its physical blocks returned to a shared pool serving multiple customer accounts. Because those blocks were not zeroed on reallocation, a subsequent container that triggered allocation of a reused physical block could read the leftover ~60 KiB that its own 4 KiB write did not overwrite. The attack was demonstrated by Oren Yomtov of Accomplish (accomplish.ai) and reported through Cloudflare's HackerOne bug-bounty program as report #3997565 on 2026-09-04. The proof of concept used a legitimate Workers Paid account: open the raw root disk at /dev/vdc, record a baseline, write a single 4 KiB block into each selected 64 KiB-aligned region corresponding to free space in the guest ext4 filesystem, then re-read the blocks and inspect only the portions the new container had not overwritten. Reading a previously unmapped region returned zeroes without allocating a block, but writing 4 KiB into an unmapped region forced dm-thin to allocate a full physical 64 KiB block, leaving 60 KiB of a prior tenant's data recoverable. This is a direct-volume-access primitive (raw reads of /dev/vdc) rather than a VM/container escape in the code-execution sense.

To validate attribution of recovered blocks to foreign tenants, the researchers used ext4 metadata_csum directory-block checksums to distinguish their own filesystem's blocks from foreign ones. Across six production placements they examined 5,614 testable directory blocks, found none attributable to their own filesystem, and identified 2,700 distinct foreign directory inodes; a controlled validation of 162 deliberately created/deleted test blocks was 100% correctly attributed. Residual material was observed on 18 of 24 placements and 20 of 22 underlying nodes spanning four continents. Recovered block types included directory structures, database pages, structurally complete SQLite databases, Chromium browser profiles, .env files, and credential files. The submission contained no third-party filenames, identifiers, credentials, hostnames, or recovered content values, and the researchers confirmed the recovered data was securely deleted in line with HackerOne disclosure policy.

The confidentiality impact crossed the tenant-isolation boundary: an attacker with a Workers Paid account could opportunistically recover residual data from blocks previously used by other customers' workloads on the same underlying host, including filesystem metadata, directory structures, database pages, and application data. The attacker could not select a victim, access an actively attached disk, modify another customer's live data, or affect workload availability, and residual data was not guaranteed to be present (placement was automatic and opportunistic). Cloudflare remediated by removing skip_block_zeroing from the dm-thin pool configuration fleet-wide, which stopped new residual exposure and was independently confirmed by the researchers; because that change did not sanitize blocks already mapped into existing thin devices or cached dm-thin snapshots of OCI image layers, Cloudflare additionally retired all running container disks, removed cached image snapshots created before mitigation, drained hosts off-peak, restarted VMs, and cleared each host's image cache so all disks and cached layers were recreated with zeroed allocations. Cleanup of all pre-mitigation cached snapshots completed on 2026-09-19.

Cloudflare reported no evidence of any malicious actor abusing the vulnerability; retained disk-I/O telemetry was scanned against the attack's signature (a 4 KiB write to a previously unmapped region triggering allocation of a reused 64 KiB block, followed by reads recovering substantially more data than the container wrote), and only researcher and internal validation activity matched. No CVE was assigned and no CVSS score was published. The disclosure notes this is the sixth sandbox/isolation escape Accomplish has published since July 2026, following escapes from Claude Cowork (SharedRoot), Claude Code (Beltdown), Cursor CLI (Beltdown2), Docker's hypervisor, and an OpenAI Codex sandbox — underscoring that multi-tenant isolation can fail in many ways, including at the storage layer. The underlying Linux behavior is documented upstream: the dm-thin target sets discard_zeroes_data_unsupported because partial discards are not guaranteed to be zeroed before reuse, so secure erase must be explicit.