Cloudflare Containers Flaw: Cross-Tenant Residual Disk

Tue Sep 29

A paid Cloudflare Workers account was enough to read leftover disk from someone else’s container. On 4 September 2026, security researcher Oren Yomtov of Accomplish reported a multi-tenant isolation flaw in Cloudflare Containers and Cloudflare Sandboxes through HackerOne. The bug sat in how deleted root disks returned physical blocks to a shared thin-provisioning pool: a 4 KiB write into free space could allocate a reused 64 KiB block and leave roughly 60 KiB of prior-tenant residual data readable. Cloudflare’s disclosure — prepared with the researchers — says the company fully remediated the issue, found no evidence of malicious exploitation in retained disk-I/O telemetry, and has no evidence that customer data was compromised. Canonical BreachHistory record: https://breachhistory.com/cloudflare/cloudflare-containers-cross-tenant2026.

This is not a classic dump-and-sell breach with a victim census. BreachHistory indexes recordsAffected: 0 because Cloudflare and the researchers did not publish an attested count of affected customers, files, or identities. What was verified is the vulnerability class, the Workers Paid prerequisite, the residual-block technique, the kinds of material recovered in controlled testing, the mitigation timeline through 19 September 2026, and Cloudflare’s finding that customers need take no action. Primary sources: the Cloudflare Containers cross-tenant vulnerability post, BleepingComputer’s 27 September summary, and Accomplish’s note Escaping the Cloudflare sandbox.

What happened

Cloudflare Containers run workloads on multi-tenant infrastructure. Placement is automatic; customers cannot pick the underlying host. Each container sits inside a dedicated Firecracker virtual machine. The writable root disk is presented to the guest as /dev/vdc and is backed by Linux device-mapper thin provisioning (dm-thin).

Thin provisioning allocates physical storage only when a virtual disk writes to a previously unmapped region. On the affected pools, the thin-block size was 64 KiB. When a container’s thin volume was deleted, those physical blocks went back into a pool that served workloads belonging to multiple customer accounts.

The dangerous knob was skip_block_zeroing. With that option set, dm-thin does not clear newly allocated blocks before handing them to a container. A full 64 KiB write would replace prior contents. A smaller write would not. That gap is the entire bug.

Yomtov’s proof of concept did not rely on reading unmapped thin regions — those correctly returned zeroes without allocating a physical block. Instead the PoC identified 64 KiB-aligned regions corresponding to free space in the guest’s ext4 filesystem, then wrote one aligned 4 KiB block into each region. When that write hit an unmapped thin block, dm-thin allocated a physical 64 KiB block from the shared pool. Only 4 KiB was overwritten. The remaining ~60 KiB could still hold data from a previous container. A subsequent raw-device read of /dev/vdc could therefore observe bytes the new tenant had never written.

In plain English: create a fresh container, poke free space with tiny writes, and read the leftover tails of reused blocks — that was enough to cross the tenant-isolation boundary on hosts that still held uncleared prior-customer material.

Timeline — report to cleanup

Cloudflare published a tight incident clock (all times UTC from the vendor post):

4 September 2026, 15:26: Oren Yomtov reports via HackerOne (report 3997565).
4 September, 18:45: Cloudflare opens a security incident and confirms the production setup that caused the flaw.
4 September, 21:27–23:15: Runtime fix and pool changes merge; rollout begins.
7 September, 06:13: Rollout completes; clearing of old pool data begins.
14 September: Researchers confirm the proof of concept no longer works; Cloudflare awards the bounty.
19 September, 15:03: Cleanup of all pre-mitigation cached snapshots finishes across the affected fleet.

From first report to a merged runtime fix measured in hours. Full fleet hygiene — retiring disks and wiping cached image snapshots that could still carry old mappings — took until 19 September. That second phase matters as much as disabling skip_block_zeroing, because zeroing new allocations alone does not sanitize blocks already mapped into running disks or inherited through cached OCI layer snapshots.

How the exploit worked

The submission’s steps, as Cloudflare documented them:

Create a container on a Workers Paid account.
Open the writable root disk at /dev/vdc.
Read the disk and record a baseline.
Write one 4 KiB block into each selected 64 KiB region corresponding to ext4 free space.
Read the resulting blocks again.
Examine only the portions not overwritten by the new container.

Attribution of “foreign” versus self-owned residual used ext4 metadata_csum directory-block checksums, which incorporate filesystem- and inode-associated values. Across six production placements the researchers reported 5,614 testable directory blocks, zero of which belonged to their own filesystem, and 2,700 distinct foreign directory inodes. A control test against blocks they had deliberately created and deleted attributed all 162 blocks correctly to their filesystem.

Residual material showed up on 18 of 24 placements and 20 of 22 underlying nodes across four continents. That is a high hit rate for opportunistic residual recovery. It is also not a guarantee that every placement leaked, or that every recovered block was useful application data. Cloudflare is explicit that residual data was not guaranteed to be present, and that an attacker could not target a particular customer, workload, host, or dataset. Placement luck and reclaim timing decided what, if anything, appeared in the unread tails.

What this is not: a write path into another customer’s live disk, a denial-of-service against neighbors, or a way to attach to an actively mounted volume belonging to someone else. Cloudflare states the researchers did not demonstrate modification of another customer’s active data or impact to workload availability. The boundary that failed was confidentiality of released blocks — leftover storage after a prior tenant’s thin volume was deleted and those blocks were recycled without zeroing.

What data could have been exposed

Keep the inventory tied to what the disclosures actually say.

Material types observed or described in testing

Filesystem metadata and directory structures
Database pages and structurally complete SQLite databases
Application data more broadly (Cloudflare’s impact language)
Chromium profiles, .env files, and credential files (Accomplish’s public summary, echoed by BleepingComputer)

That list is sobering for anyone who runs agents, browser automation, or secret-bearing services inside Cloudflare Containers or Sandboxes. A SQLite file recovered from a prior tenant is not “just metadata.” A Chromium profile can hold cookies and session material. A .env fragment can hold API keys. Directory listings alone can reveal project layout, customer names embedded in paths, and tooling choices.

What the HackerOne package did not contain

Cloudflare says the materials provided to the company contained counts, block offsets, sizes, checksum results, and truncated hash prefixes — not third-party filenames, identifiers, credentials, hostnames, addresses, or recovered content values. The researchers used scripts that output aggregate counts and format checks, not recovered file contents, for the evaluation Cloudflare reviewed. They later confirmed recovered data under their control remained confidential and was securely deleted after submission, consistent with Cloudflare’s HackerOne disclosure policy.

Cloudflare’s public conclusion from that evaluation: no real customer data was exposed in the researchers’ test workflow as presented. Separately, Cloudflare reviewed historical disk-I/O telemetry for the characteristic 4 KiB write / oversized residual-read pattern, attributed matching activity to the researchers and to Cloudflare engineers doing authorized validation, and identified no additional activity consistent with the reported technique. The company says it saw no evidence that this specific attack vector was exploited by anyone else.

Those statements are strong, not a mathematical proof that nobody else tried quieter variants before 4 September. BreachHistory records Cloudflare’s forensic posture as stated — and still refuses to invent a victim headcount.

What was not exposed — or not demonstrated

No attested census of affected Cloudflare customers or end users.
No confirmed dump of live customer databases sold or posted.
No ability, in the disclosed PoC, to choose a victim by name or to read an actively attached neighbor disk.
No demonstrated integrity or availability impact against other tenants’ running workloads.
No customer-side patch required after Cloudflare’s fleet remediation.

If you are hunting for “was I affected” in the classic breach sense — a notice naming your account and a list of fields — Cloudflare’s message is that remediation is complete and no further customer action is required. That is different from saying residual blocks never held interesting bytes while the misconfiguration was live. The researchers’ hit rates show residual material was common on tested hosts. The open question for any specific tenant is whether their deleted blocks were reassigned and sampled by anyone other than the authorized researchers. Cloudflare’s telemetry review found no such activity matching the signature.

Who is at risk

Cloudflare Containers and Sandboxes customers (Workers Paid)

Anyone who ran Containers or Sandboxes workloads while skip-zeroing was in effect was theoretically in the residual-data pool. Sandboxes and Browser Run share the same disk implementation, Accomplish notes, and were affected too. Practical stakes depend on what those containers held. Ephemeral compute that never touched secrets is a different conversation from long-lived agent sandboxes that wrote SQLite state, downloaded Chromium profiles, or mounted .env files onto the root disk. If secrets routinely landed on disk, residual risk grows — even when Cloudflare’s evaluation did not surface those secrets to HackerOne reviewers.

Neighbor tenants on the same host

The attacker model is another Workers Paid customer, not a random internet scanner. That narrows the adversary set but does not make the bug academic. Cloudflare’s inability for an attacker to aim at a specific victim is a real constraint. It is also the classic shape of opportunistic cloud residual attacks: you get whoever was deleted just before you arrived.

End users of apps hosted on Containers

Downstream consumers of a SaaS product built on Cloudflare Containers are one step removed. Their risk is whatever their vendor stored on container disks and whether that vendor rotates credentials that might have lingered in residual blocks. Cloudflare’s “no customer action” guidance is aimed at Cloudflare account holders. Application owners still own their own secret-rotation hygiene.

People who never used Containers or Sandboxes

Workers apps that never touched Containers, ordinary CDN/WAF customers, and DNS-only accounts are outside this isolation boundary. Do not conflate this disclosure with a Cloudflare global edge breach. The blast radius is the Containers/Sandboxes storage path on multi-tenant hosts configured with skip-zeroing.

Industry context

Accomplish framed the Cloudflare finding as the sixth sandbox escape the team has published since July 2026, after work against Claude Cowork (SharedRoot), Claude Code and Cursor CLI (Beltdown / Beltdown2), Docker’s VMM, and OpenAI Codex’s sandbox. Different products, same season: agent and code-execution sandboxes are under sustained scrutiny because they are where untrusted code, browser state, and secrets collide.

The Cloudflare case is specifically a storage-reclamation bug, not a Firecracker guest escape into the host kernel. Firecracker still presented an isolated VM; the leak was in how dm-thin recycled physical blocks across tenants when zeroing was skipped. That puts it in the same family as classic cloud residual-disk and incompletely erased volume issues — the kind of flaw that looks boring until you recover a structurally complete SQLite database that was never meant to leave the prior guest.

For platform engineers, the lesson is familiar. Performance shortcuts that skip sanitizing reused blocks trade CPU and latency for confidentiality. Multi-tenant thin pools make that trade global. Cached image snapshots that inherit old mappings extend the exposure window even after you flip the zeroing default. Cloudflare had to do both: disable skip_block_zeroing and retire disks plus clear pre-mitigation snapshot caches.

What Cloudflare said

Cloudflare’s disclosure is unusually technical and collaborative. It walks through allocation behavior, PoC steps, validation statistics, mitigation phases, and telemetry conclusions. The customer-facing bottom line is blunt: the vulnerability is patched, remediation does not require further action by Cloudflare customers, and Cloudflare found no evidence of malicious abuse of this vector.

BleepingComputer’s Bill Toulas summarized the same arc on 27 September 2026: Workers Paid residual recovery, 4 KiB / 64 KiB mechanics, residual on most tested placements, aggregate-count-only researcher scripts, mitigations complete by 19 September, no customer action. Accomplish’s public post is shorter and more punchy — directory listings, SQLite, Chromium profiles, .env, credentials — and points readers to the joint Cloudflare write-up for the full technical breakdown.

Phishing patterns to expect

A vendor disclosure this detailed will spawn opportunistic lures even when Cloudflare says customers need do nothing:

Emails claiming “Cloudflare Containers residual-disk remediation” that demand you open a dashboard link and paste an API token
Messages offering a “free cross-tenant exposure scan” that ask you to deploy a worker from an untrusted package
Support-style calls that already know you use Workers Paid and insist you must rotate every secret via a shared screen session
Fake HackerOne or bounty follow-ups asking for production credentials to “validate residual cleanup”

Real Cloudflare guidance for this incident lives on blog.cloudflare.com and the dashboard you navigate to yourself. Cloudflare is not asking customers to install an emergency container agent over email. Treat any party that creates urgency around tokens, crypto payment, or remote access as hostile until proven otherwise through an out-of-band channel you already trust.

What you should do

Read Cloudflare’s post once, end to end. The authoritative customer message is no action required for the platform fix. Do not invent emergency procedures that contradict the vendor.
Inventory what your containers wrote to disk. List SQLite paths, Chromium/user-data directories, .env files, credential caches, and any other secret-bearing files that routinely landed on the root filesystem.
Rotate secrets that lived on disk. Even with Cloudflare’s “no evidence of exploitation” finding, rotation is cheap insurance for API keys, database passwords, and session material that may have existed in residual blocks while skip-zeroing was enabled.
Prefer external secret stores over files on the root disk. Short-lived memory and sealed secret managers beat long-lived .env files on multi-tenant scratch.
Review agent and browser-automation workloads. Chromium profiles and SQLite state are exactly the residual types Accomplish highlighted.
Watch for official Cloudflare updates, not tracker gossip. If Cloudflare later revises its exploitation assessment, update from the primary blog.
Ignore census rumors. There is no published victim headcount. Anyone selling a list of “Cloudflare Containers breach victims” is inventing product.
Brief security and platform teams once. This was residual-block confidentiality on dm-thin, not a Firecracker host escape — so future reviews ask the right questions about zeroing and snapshot inheritance.
If you are a downstream SaaS customer of a vendor on Containers: ask whether secrets lived on container disks in early September 2026 and whether they rotated anything as a precaution.

What platform teams should take from this

If you operate multi-tenant thin pools, treat skip-zeroing as a confidentiality decision, not only a performance flag. Audit whether deleting a volume truly sanitizes physical blocks before reassignment. Track cached image snapshots and prepared layer mappings as part of the same trust boundary — Cloudflare had to clear them separately after the runtime fix. And when researchers report with aggregate-only scripts, preserve enough disk-I/O telemetry to hunt the write/read signature later.

For application teams on Workers Paid: assume container root disks are hostile-shared storage after delete unless the platform documents zeroing. Write less that matters. Rotate what you must write.

Canonical record and sources

BreachHistory catalogs this as a verified Cloudflare platform vulnerability disclosure with mitigations completed by 19 September 2026 and recordsAffected: 0 because no attested customer or identity census exists: https://breachhistory.com/cloudflare/cloudflare-containers-cross-tenant2026.

Primary and secondary sources:

Hold the right two thoughts. The Cloudflare Containers isolation flaw was real, reproducible on production placements, and serious enough that residual directory inodes, database pages, and SQLite structures crossed tenant boundaries in testing. Cloudflare moved fast, disabled skip-zeroing, retired disks, cleared cached snapshots, and reports no evidence of malicious exploitation or customer-data compromise from the researchers’ aggregate-only evaluation. Act on secret hygiene if your workloads wrote sensitive files to container disks. Do not invent a victim census the primary sources never published.

For Workers Paid teams on Containers or Sandboxes in early September 2026, the practical next step is inventory and selective rotation — not panic patching of a knob Cloudflare already flipped.