Cloudflare disclosed and fixed a cross-tenant data exposure vulnerability in its Containers platform that let a customer on any Workers Paid account recover leftover disk data written by a different customer’s workload on the same physical host. The bug also reached Cloudflare Sandboxes and the Browser Run service inside Browser Rendering, since all three share the same underlying container disk implementation. Security researcher Oren Yomtov of Accomplish reported the flaw through Cloudflare’s HackerOne program on September 4, 2026; Cloudflare says it completed remediation across its fleet by September 19 and published a full writeup on its blog after confirming no evidence of in-the-wild exploitation.
What’s broken
Cloudflare Containers back each tenant’s ephemeral filesystem with a Linux dm-thin thin-provisioned storage pool — disk space is allocated in blocks on demand rather than reserved up front, which is what makes fast, dense multi-tenant container scheduling practical. By default, dm-thin zeroes a block before handing it to a new consumer, so a freshly allocated block never contains a previous owner’s data. Cloudflare’s pool was configured with skip_block_zeroing set, which disables that safety net for performance reasons.
The pool allocates storage in 64 KiB blocks, but a container write can be as small as 4 KiB. When a container wrote 4 KiB into a previously unmapped region, the pool allocated the full 64 KiB block to back it — and with zeroing skipped, the remaining 60 KiB retained whatever a prior tenant’s container had written there before its disk was torn down and the block was recycled back into the shared pool. A tenant that deliberately wrote small, sparse chunks across a fresh container’s disk and then read back the full blocks could recover that residual 60 KiB directly — no exploit chain, privilege escalation, or sandbox breakout required, just a normal filesystem write followed by a normal read.
Yomtov’s team validated the impact empirically: testing found recoverable residual material on 18 of 24 container placements they sampled, spanning 20 of 22 distinct underlying physical nodes. What came back included directory listings, structurally complete SQLite database files, Chromium browser profile data, .env files, and credential material — the kind of data that routinely ends up in a container’s working filesystem during normal application execution, not data an attacker had to go looking for.
Impact
Anyone holding a Workers Paid account could attempt this against any other tenant sharing the same host — there’s no authentication bypass or target selection involved, just co-location on shared infrastructure, which is the entire premise multi-tenant cloud platforms ask customers to trust. Cloudflare Containers, Sandboxes, and the Browser Run feature all inherited the exposure since they share the disk backend. Cloudflare states its post-incident review of logs and telemetry found no evidence that any customer’s data was actually recovered by another tenant before the fix, but that assurance rests on retained telemetry rather than a cryptographic guarantee, and a bug this straightforward to trigger is the kind that’s easy to exploit quietly.
This is also the sixth sandbox-escape-class finding Accomplish has published since July — prior disclosures hit Claude Cowork’s SharedRoot mechanism, Claude Code, Cursor’s CLI sandbox, Docker’s hypervisor isolation, and OpenAI’s Codex sandbox. The pattern across all six is the same: isolation boundaries in fast-moving container and sandbox products that were tuned for performance without re-verifying the zeroing, cleanup, or reset guarantees the isolation model depends on.
Mitigation
Cloudflare removed skip_block_zeroing from the dm-thin pool configuration fleet-wide, restoring the default behavior of clearing newly allocated blocks before they’re exposed to a container. It also retired all existing container disks that could carry stale mappings and cleared cached snapshots referencing the old (unzeroed) block layout. Cloudflare states these changes were applied automatically across its infrastructure and that no customer action is required.
Customers who ran sensitive workloads in Cloudflare Containers, Sandboxes, or Browser Rendering before September 19 and want independent assurance should treat any credentials, API keys, or session tokens that were present in a container’s filesystem during that window as potentially exposed and rotate them — Cloudflare’s “no evidence of exploitation” finding is based on its own telemetry, not a guarantee applicable to every workload. Teams building on any thin-provisioned, multi-tenant container storage backend — self-hosted or otherwise — should confirm block zeroing is enabled by default and treat skip_block_zeroing-style performance flags as a tenant-isolation decision, not a purely operational one.
Sources: