Cloudflare disclosed on 24 September that its Containers platform, and the Sandboxes built on it, could give one customer's workload readable fragments of another customer's old disk. A researcher found them on 18 of 24 placements tested.
The cause was a single storage setting, skip_block_zeroing, which let 64 KiB blocks move between tenants without being wiped first. Write 4 KiB into a fresh block and the other 60 KiB still held someone else's data.
If your agents run code in a hosted sandbox, "the sandbox was deleted" and "the data is gone" are two separate claims. Keep secrets off the sandbox disk, and encrypt anything that has to land there with a key that dies with the run.
What the researcher found
Oren Yomtov of Accomplish reported the issue through HackerOne on 4 September at 15:26 UTC. Cloudflare merged a runtime fix the same day, finished the main rollout on 7 September, and cleared the last cached snapshots on 19 September. The public write-up went out five days after that.
The mechanism is ordinary Linux storage. Cloudflare backs each container's root disk with a thin volume from dm-thin, the device mapper's thin provisioning target. Thin volumes don't reserve space up front. They grab physical blocks from a shared pool the first time something writes to them, and when a volume is deleted, its blocks go back into the pool.
That pool served workloads from multiple customer accounts. By default, dm-thin zeroes a block when it hands it to a new volume. With skip_block_zeroing switched on, it doesn't. The kernel documentation describes the option in one line: skip the zeroing of newly provisioned blocks.
So the attack was a small write. Start a container, write 4 KiB into a part of the disk the filesystem hasn't used yet, and the pool allocates a whole 64 KiB block to hold it. Your 4 KiB overwrote the start of the block. You could read the other 60 KiB, and it held whatever the previous owner left behind.
What was on those blocks
Yomtov tested 24 container placements across 22 nodes on four continents. Residual data from other tenants showed up on 18 of the placements and 20 of the nodes. Using ext4 checksums to tell foreign metadata apart from his own, he counted 2,700 distinct directory inodes that didn't belong to him.
Cloudflare's own summary lists what that material included: directory structures, database pages, and structurally complete SQLite databases. Exploiting it required nothing more than a Workers Paid account.
The limits matter too, and Cloudflare was clear about them. The technique couldn't reach disks attached to running containers, couldn't modify anyone's live data, and didn't affect availability. You got leftovers from volumes that had already been deleted, in random fragments you didn't choose. Cloudflare says it went through logs and telemetry and found no activity beyond the researcher and its own engineers, and that customers don't need to do anything.
I believe that, and the response was fast. Two weeks from report to a clean fleet, including retiring every pre-fix disk and draining hosts during off-peak hours, is good incident work.
Why this lands on agent builders
Cloudflare pitches Sandboxes at people who need to run code they didn't write, and in 2026 that mostly means code an agent wrote. A coding agent clones a repo, installs dependencies, runs the test suite, writes a scratch database, and exits. Then the orchestrator deletes the sandbox and the next task gets a fresh one.
Look at what sits on that disk during a normal run. There's a .env file the agent created so the tests would pass, and a cloned private repository. A SQLite file holds fixtures copied from staging. The package manager cache sits there with an auth token in its config, and so does a shell history.
Most teams I work with treat sandbox deletion as the cleanup step. The run is disposable, so the disk is disposable, so whatever was on it is gone. This disclosure shows that the last step of that chain depends on a storage setting two layers below the API you call, and you can't see or test it.
There's also a volume effect. A developer's laptop might create a few containers a day. An agent platform can create and delete thousands of sandboxes an hour, and every delete returns blocks to the pool. The more your system treats compute as throwaway, the more of your data passes through that pool.
It's also a shared-surface problem, the same family as the package cache story from August. Anything that two tenants touch in sequence can carry data from one to the other, whether that's a cache, a registry, or a free list of disk blocks. Nobody designs these as channels, but they end up as channels anyway.
What I'd change in an agent sandbox setup
None of this means leaving hosted sandboxes. Most cloud storage reuses physical blocks somewhere, and Cloudflare now zeroes them by default. The point is to stop relying on deletion as your data control.
Keep secrets off the sandbox disk. Inject credentials as environment variables or short-lived tokens that the agent fetches at run time, and scope them to the task. If the agent needs a .env file, write it to a tmpfs mount, which lives in memory and never touches the block device.
Encrypt the working directory with a per-run key. If the sandbox has to write sensitive data to disk, put it on an encrypted volume or an encrypted file layer keyed to that run. Throw the key away when the run ends. Leftover blocks are then ciphertext, and it no longer matters whether the provider zeroes them.
Don't copy production data into sandboxes. The SQLite databases in this story are exactly what an agent produces when it pulls realistic fixtures to test a migration. Use synthetic data or a masked extract, and make that a rule in the harness, not a suggestion in the prompt.
Ask your provider the boring question. Does reclaimed storage get zeroed or crypto-erased before another tenant can allocate it? Is that tested? The honest answer tells you whether their isolation claim covers disk reuse or only running processes.
Check your exposure window. If you ran Cloudflare Containers or Sandboxes with sensitive data between 4 and 19 September, write down what was on those disks. Cloudflare found no misuse, and that should close it, but you want that list before someone asks for it.
The part the diagram leaves out
Architecture diagrams draw a sandbox as a box with a lock on it. The box covers processes, network and the filesystem while the container runs, and those parts worked here.
What the box leaves out is what happens after the run ends. The delete call returns in milliseconds, and the blocks it freed get handed to the next tenant. For two weeks in September, at one of the largest edge providers, those blocks went out unwiped. The fix is in, but your own design should keep the data safe even when a storage setting like this one is wrong.