Executive Summary
Cloudflare Containers, Sandboxes and Browser Run shared a disk allocation bug that crossed the tenant boundary. A customer on a Workers Paid plan could recover disk blocks a previous customer’s container had already used on the same host. The fault was not in the container runtime. It was thin provisioning with block zeroing switched off, so a released 64 KiB block kept its old bytes.
Accomplish found residual data on 18 of 24 container placements and 20 of 22 hosts across four continents, including structurally complete SQLite databases. Cloudflare remediated the flaw, found no evidence of exploitation, and told customers to take no action. That answers the incident. It does not answer the pattern. This is the sixth sandbox isolation failure the same research team has published since July, and the first aimed at the storage layer rather than the runtime.
Run someone else’s code and the platform promises to keep it away from everyone else. Most people file that promise under the runtime. Cloudflare just showed it is also a storage promise, and the storage half was broken. A sandbox read bytes that had never been written to it.
Cloudflare fixed the flaw in Cloudflare Containers, Cloudflare Sandboxes and Browser Run. A customer on a Workers Paid plan could recover residual disk blocks from another customer’s container on the same physical host. Cloudflare published the writeup with the researchers at Accomplish, who reported it on September 4 through the bug bounty program.
The bug is a 4 KiB write against a 64 KiB block
Cloudflare runs container disks on Linux device-mapper thin provisioning. Thin provisioning hands out storage in 64 KiB blocks and reuses a block once the workload holding it is deleted. By default the kernel zeroes a block before the next tenant gets it. Cloudflare had the zeroing step turned off.
That setting is where the leak lives. A full-block write replaces everything inside a reused block. A smaller write replaces only the bytes it touches. So a 4 KiB write into a fresh container allocated a recycled block, overwrote 4 KiB, and left the other 60 KiB of the previous tenant’s data readable through a raw read of the block device.
A second path led to the same place. A new container could inherit block mappings from a cached layer without allocating them, which left unused regions of its own disk readable before any write. Both routes ended with a container reading data that belonged to someone else.
The runtime was isolated. The disk underneath was shared
Every multi-tenant platform draws the boundary in the same place. Separate the process, the network and the filesystem, then call it isolated. The disk is treated as below the line, because the guest only sees its own block device. Thin provisioning breaks that assumption quietly. The block device is real, it is shared at the host, and the guest can read it raw.
Cloudflare deserves credit for the response. It fixed the allocation path, rolled the change out automatically, and reviewed logs and telemetry for abuse. It found only the researchers’ probes and its engineers’ validation. An attacker also could not pick a victim or touch an actively attached disk, because exposure depended on placement and on which released blocks the pool reassigned.
Those limits are real, and they are still the wrong frame. You could not choose your target describes the attacker’s constraint, not a property of the system. A tenant boundary is either enforced or it is probabilistic. The device-mapper thin provisioning guide treats zeroing as the step that keeps it enforced.
Patch one layer and the next bug sits in another
This is the sixth sandbox isolation escape Accomplish has published since July. The list runs SharedRoot in Claude Cowork, Beltdown in Claude Code, Beltdown2 in Cursor’s command line, Docker’s virtual machine monitor, and OpenAI’s Codex sandbox. Each was a different layer. Isolation is not one boundary. It is a stack, and review effort clusters at the top while the bottom goes unexamined.
Our own coverage keeps landing on that seam. We argued that every AI agent should get its own kernel, because a shared kernel is where isolation leaks first. Google shipped an agent runtime built for idle sandboxes, and CISA put Linux kernel bugs under every container on its exploited list. Cloudflare adds the floor below all of it. The runtime can be perfectly isolated while the storage serving it is not.
The practical lesson is narrow. If two workloads share a thin pool, whether they share bytes is a configuration question, not a runtime guarantee. Configuration questions need an owner and a test.
Three questions for your own environment. Who owns the zeroing setting on your thin pools, and is it on? When a workload is retired, what erases its blocks before they go back to the shared pool? And if a sandbox and the storage under it disagree about the isolation boundary, which one gets tested?
Related reading. Our case for giving an agent’s permissions to the image it runs, and why agent state does not belong in etcd.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.
[…] escape as a fleet problem and keep host credentials off the sandbox network. The pattern repeats. Cloudflare’s sandbox flaw in September let one tenant read the last tenant’s disk, and a container escape shipped in Ubuntu without […]