Cloudflare's Container Isolation Leaked Between Customers. The Product Most Exposed Is the One Built for AI Agents

Cloudflare published a post-mortem on September 24 describing a flaw in its Containers platform that let one customer's workload read disk data left behind by another customer's. The company says the issue is fully remediated and that a review of historical disk-I/O telemetry turned up no evidence anyone outside the reporting researcher and its own engineers used it. The disclosure is unusually detailed and the response was unusually fast. Neither changes what the flaw was: a failure in the boundary the entire product is sold on.

What went wrong

Containers, and the Sandboxes product built on top of them, run customer workloads on shared hosts backed by thin-provisioned storage. Disk space is handed out in 64 KiB blocks as a workload writes, and returned to a shared pool when that workload is destroyed. Cloudflare had disabled the storage layer's default behaviour of zeroing a block before handing it to its next occupant — a skip_block_zeroing setting on its dm-thin pools, chosen for performance. Blocks could therefore reach a new container still carrying whatever the previous one had written.

What that produces is residual-data exposure, not live access. Cloudflare's account is specific about the limits: an attacker could not select a victim, could not read a disk while it was attached to a running workload, and could not modify another customer's data or affect its availability. What could come back was filesystem metadata, directory structures, database pages and application data belonging to whoever had previously occupied that block on that host.

How much of it there was

Oren Yomtov of Accomplish, who reported the flaw through Cloudflare's HackerOne programme, published measurements that make the scope concrete. Residual foreign data showed up in 18 of 24 container placements across four continents, and on 20 of 22 underlying machines. Across 5,614 testable directory blocks the team identified roughly 2,700 distinct directory inodes belonging to other tenants, along with structurally complete SQLite databases.

That is not a narrow edge case triggered by an unlucky allocation. It is the ordinary behaviour of the platform.

Why Sandboxes is the uncomfortable part

Containers is infrastructure. Sandboxes is the thing Cloudflare sells on top of it, and its documentation is explicit about what it is for: executing code generated by large language models, and "AI agents, code assistants, and autonomous systems that need to run untrusted code."

Consider what a working agent leaves on disk while it does that. Checked-out repositories. .env files. Short-lived API tokens written somewhere so a subprocess can read them. SQLite state carrying the transcript of whatever the agent was doing. The entire category of artefact an agent needs in order to be useful is the same category that is worst to leave sitting in a recycled block. A sandbox is a boundary drawn around code you have decided not to trust; the value of the product is entirely in the boundary holding.

What a customer can actually do

Nothing, in the patching sense. There is no CVE, no version to move to, and no customer-side control that was involved. The fix was server-side and is already deployed fleet-wide.

The real question is credentials, and it is a judgement call rather than an instruction. Cloudflare's telemetry review establishes that this particular technique was not used by others; it does not and cannot establish that no secret ever resident in a Container or Sandbox before September 7 was seen. Any organisation that kept long-lived credentials inside those workloads should weigh a rotation against the cost of doing one. That is a thin answer, which is the nature of residual-data exposure: it leaves nothing in the victim's own logs to find.

Credit, and the trade underneath

The timeline deserves saying out loud. Report to confirmed-in-production in three hours and nineteen minutes; report to merged fix in six hours; rollout underway the same day. Most vendors do not acknowledge a submission that fast. Publishing the mechanism, including the admission that the unsafe behaviour was a deliberate performance setting rather than an oversight, goes well past what disclosure norms demand.

The broader point survives the good handling. The industry has spent two years moving untrusted code execution off customers' own machines and onto shared multi-tenant platforms, because agents need somewhere cheap and instant to run. That trade buys speed and cost, and what it sells is the assumption that isolation holds at every layer — including the unglamorous ones nobody markets, like block allocation. Here it held everywhere except the storage pool.

Sources: Cloudflare Blog · The Hacker News · Cyber Security News · GBHackers · Cloudflare Sandbox SDK documentation