The short answer
A storage setting in Cloudflare Containers skipped wiping reused disk blocks, so a new container could read fragments left by another customer's deleted one. Cloudflare fixed it within days, found no sign of abuse and requires no customer action. If you run workloads on Cloudflare Workers and its container runtime, the practical takeaway is simple: never assume a disk you delete is truly empty.
Treat any shared cloud disk as untrusted once you release it, and keep secrets off it in the first place.
What did Cloudflare disclose?
On September 24, 2026, Cloudflare published a post-mortem on a cross-tenant data exposure in Containers, its container runtime that sits alongside Workers, and in Sandboxes, which run untrusted code such as AI-agent tasks. The company said a Workers Paid customer could have recovered residual data from storage blocks previously used by other customers' containers on the same host.
Security researcher Oren Yomtov of Accomplish reported the issue through Cloudflare's HackerOne program on September 4 at 15:26 UTC. Cloudflare confirmed it in production about three hours later and merged a runtime fix that evening. BleepingComputer and The Hacker News covered the disclosure over the following days.
According to Cloudflare, recovered blocks contained directory structures, database pages and structurally complete SQLite databases. The researchers' own write-up, as summarized by both outlets, also lists Chromium browser profiles, .env files and credential files. The researchers say their scripts returned only aggregate counts, not file contents.
How did data cross between tenants?
Container disks were carved out of a shared pool using Linux device-mapper thin provisioning. The pool had the skip_block_zeroing option turned on, which tells the kernel not to zero a newly allocated block before handing it out. Blocks were 64 KiB. When a new container wrote only a few kilobytes into a freshly assigned block, the rest of that block still held whatever the previous owner had written.
Skipping zeroing is a common performance trade-off: wiping every block costs I/O. It is safe when one tenant owns the pool and dangerous when many do. Cloudflare's fix removed the option, retired every container disk created before the mitigation, cleared cached image snapshots and drained and restarted hosts during off-peak hours.
Two limits kept the risk lower than it sounds. An attacker could not pick a victim, and could not read a disk that was still attached to a running container. What leaked was whatever happened to be left on released space.
What it means for US & EU software teams
First, “deleted” is not “erased” on shared infrastructure. This is the same class of bug as residual data in reused cloud volumes or GPU memory, and it will show up again with other providers. Your threat model for any multi-tenant platform, including newer Cloudflare products, should assume released storage may be readable by someone else.
Second, sandboxes for AI agents raise the stakes. Teams increasingly run agent-generated code, browser sessions and scratch databases in short-lived containers. Those workloads create exactly the data this bug exposed: browser profiles, local SQLite files and .env files with API keys. Short-lived does not mean low-risk if the disk outlives the container.
Third, compliance still depends on your own controls. Cloudflare found no misuse, so this is not a notifiable breach for most customers. But under GDPR, HIPAA or SOC 2 you are expected to show that personal data and credentials are protected even when a provider's isolation fails. Encryption at the application layer and short-lived credentials are what let you say so.
What should you do now?
- No emergency patch is needed. Cloudflare applied the fix platform-wide; there is nothing to upgrade on your side.
- Inventory what your containers write to disk. List which Containers or Sandboxes workloads store databases, browser profiles, cached tokens or
.envfiles on the root disk. - Rotate long-lived secrets as a precaution. If any container ran before September 7, 2026 with long-lived API keys or database passwords on disk, rotating them is cheap insurance.
- Keep secrets out of the filesystem. Inject credentials at runtime from a secrets manager with short TTLs instead of baking them into images or writing them to disk.
- Encrypt sensitive scratch data. For workloads that must write personal or financial data locally, encrypt it with a per-workload key so leftover blocks are useless to anyone else.
Frequently asked questions
What was the Cloudflare Containers vulnerability?
Cloudflare Containers and Sandboxes stored container disks in a shared thin-provisioned pool configured to skip zeroing reused 64 KiB blocks. When a customer's container was deleted, its blocks went back to the pool without being wiped, so a new container belonging to another Workers Paid customer on the same host could read the leftover data.
Was any customer data stolen?
Cloudflare says it found no evidence of malicious exploitation in its available disk-I/O telemetry; the only activity it saw came from the researchers and its own engineers. The researchers say their scripts returned aggregate counts rather than file contents. An attacker also could not choose a victim or read a disk that was still attached to a live container.
Do Cloudflare customers need to do anything?
No. Cloudflare says the vulnerability is patched and remediation requires no customer action. Teams that stored long-lived secrets or sensitive databases on container disks may still choose to rotate those credentials as a precaution.
When was the flaw reported and fixed?
Oren Yomtov of Accomplish reported it through HackerOne on September 4, 2026. Cloudflare merged a runtime fix the same day, finished the rollout on September 7, completed snapshot cleanup on September 19 and published its disclosure on September 24, 2026.
What kind of data could be recovered?
Cloudflare says recovered blocks held directory structures, database pages and structurally complete SQLite databases. The researchers' write-up, as reported by BleepingComputer and The Hacker News, also lists Chromium browser profiles, .env files and credential files.
Sources
Cloudflare Blog — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (September 24, 2026)
BleepingComputer — Cloudflare fixes Containers cross-tenant flaw exposing customer data
The Hacker News — Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data