Cloudflare fixes a flaw that let one container read another customer’s leftover disk data
On September 24, 2026, Cloudflare disclosed that a thin provisioning setting in Cloudflare Containers let a customer read data another customer had left behind on the same server. Customers have nothing to do, but the flaw is a reminder that cloud multi-tenant isolation can hinge on a single default parameter.
September 4, 2026. Oren Yomtov, a researcher at Accomplish, reports to Cloudflare that a paying customer can read data another customer left behind on the same server. September 19, 2026. Cloudflare finishes purging every container disk still in service. September 24, 2026. The flaw goes public. Why it matters: multi-tenant isolation is the founding promise of the cloud — and here a single provisioning setting was enough to break it, unnoticed for weeks.
What leaked, and what did not
The flaw affects Cloudflare Containers, the service that runs customer programs in containers on servers shared by many accounts. It also affects Cloudflare Sandboxes, the product built on top of it and sold as a safe place to run untrusted code — including code written by AI agents.
What leaked is not trivial: directory structures, database pages, complete SQLite databases, Chromium profiles, .env files and credential files. But the nature of the leak needs to be stated precisely. The data came from disk space that earlier containers had used and given up — not from any live workload. And an attacker could not choose whose data they recovered: they read whatever the disk happened to hand back, blind.
That distinction matters for the verdict. Nobody demonstrated the ability to modify another customer’s live data or take a workload offline. The flaw is a passive leak of remnants, not a takeover.
The cause: a 64 KB block nobody wiped
The mechanism is almost embarrassingly ordinary. Each container gets a disk built with a Linux feature called thin provisioning, which allocates storage in 64 KB blocks. When a container is deleted, its blocks return to a pool shared across customer accounts.
That is where the problem sat: the pool was configured to skip wiping a block before handing it to the next container — even though wiping is normally the default. As a result, when a new container wrote only a small amount into a reused block, the rest of the block still held the previous container’s data.
To prove it, the researchers wrote a 4 KB block into unused space, then read the whole block back at the raw disk level. The 60 KB they had not written still held bytes from an earlier container. In production, they found leftovers on 18 of 24 attempts, and on 20 of 22 underlying machines across four continents.
The number that matters is not the block size but the regularity: the leak was not an isolated accident, it was structural.
A two-step fix, then five days of silence
Cloudflare fixed it in two steps. First it turned wiping back on for newly handed-out blocks, which neutralized the reported method — the researchers confirmed on September 14 that their proof of concept no longer worked.
But that first step did not clean the blocks already mapped into running container disks, nor the cache of prepared image layers that a new container could inherit. Cloudflare therefore retired every running container disk and cleared those caches, draining and restarting servers during quiet hours. The cleanup finished on September 19; public disclosure followed five days later.
Cloudflare says it built detection signatures from the researchers’ proof of concept and its own reproduction of the attack, then ran them against the disk-activity records it retained. The result: only the researchers’ and its own engineers’ authorized testing appeared, and no sign that anyone else used the method. One limit remains: the company states neither the time span covered by those records nor how long the unsafe setting had been in place. The real duration of exposure is still unknown.
The sixth sandbox escape since July
The researchers place the finding in a series: it is their sixth code sandbox escape published since July, after results in Anthropic’s Claude Cowork and Claude Code, Cursor’s command-line tool, Docker and OpenAI’s Codex. They also note that the same disk setup affected Cloudflare Browser Run.
The accumulation is not anecdotal. It says something about how fast the industry is shipping sandboxes to run AI agent code: demand is exploding, and the isolation layers — often inherited from ordinary infrastructure building blocks — are being reused faster than they are hardened.
Why the leak went unnoticed
The flaw ran for weeks without setting off an alert, and that is exactly what makes it instructive.
Thin provisioning never physically zeroes a freed block: handing a block back to the pool is an accounting operation, not a cleanup. The wiping that should precede reassignment is a separate step — and it is the one the setting had disabled. As long as nobody reads a block back at the raw disk level, the residue stays invisible.
Standard monitoring does not see it either. A container reading another tenant’s remnants produces perfectly ordinary I/O activity on a shared disk: nothing distinguishes that read from a legitimate one. The researchers only found it because they wrote a deliberately small 4 KB block and read the whole 64 KB block back — a trick no off-the-shelf agent would perform.
The setting itself is classic configuration drift. Thin provisioning pools are usually created once, by infrastructure engineers, with performance in mind: skipping the wipe saves a write on every hand-off and feels like a harmless micro-optimization at the time. No application owner ever sees it, and no application test would catch it, because the flaw lives one layer below the container runtime. That is why the fix took a second step: even after wiping was restored, every already-mapped disk and every cached image layer had to be torn down and rebuilt. A configuration fix was not enough — the state had to be physically purged.
The duration question remains open. Cloudflare stated neither how long the unsafe setting had been active nor the time span covered by the logs it analyzed. Its detection found only authorized exploitation, but that conclusion is only as strong as the records it retained. A platform that cannot bound its exposure window cannot bound its risk either — and that is the first thing a demanding customer should ask for in a post-incident report.
Verdict
If you are a Cloudflare Containers or Sandboxes customer, you have nothing to do: the fix is deployed and Cloudflare says it found no third-party exploitation. If you design a multi-tenant platform, take the lesson of the 64 KB block: audit your thin provisioning settings, never assume wiping is on by default, and test for cross-tenant remnants yourself — a four-kilobyte probe is enough. If you run AI agents in third-party sandboxes, treat isolation as protecting the host, not your environment: never put secrets in a file a sandbox can read, and treat every execution as potentially sitting next to another tenant. The incident is also a reminder that a well-handled bug bounty report compresses the window between discovery and disclosure — here, roughly two weeks from report to fix. Treat any no-action-required notice as a prompt to check your own equivalent settings, not to move on.