Every container had its own microVM. The isolation that failed was one option on the disk pool

None of the blocks were theirs

Cloudflare published a postmortem on 24 September 2026 for a cross tenant data exposure in Containers and in Sandboxes, which is built on Containers. The number to start with is not the one in the headlines.

To work out whose data they were recovering, the researchers used ext4 directory block checksums, which under the metadata_csum feature incorporate values tied to the filesystem and the inode. That gives a way to ask of any recovered block: is this mine, or somebody else's.

Across six production placements they tested every directory block they could attribute. Cloudflare's own figures:

• 5,614 testable directory blocks
• zero of them attributable to the researchers' own filesystem
• 2,700 distinct foreign directory inodes identified

They then checked the method against blocks they had deliberately created and deleted in their own test filesystem, and it correctly attributed all 162 of them. So the technique can recognise their own data, and among 5,614 blocks it found none of it.

Widening out: residual material on 18 of 24 placements and 20 of 22 underlying nodes, across four continents. The recovered block types included directory structures, database pages, and, in Cloudflare's words, "structurally complete SQLite databases".

What that does not establish, and Cloudflare's own caveats are good ones. The technique could not target a particular customer, workload, host or data. It could not read an actively attached disk. It did not demonstrate modification of anyone's live data or any effect on availability. Residual data was not guaranteed to be present. Exploitation required a paid Workers account. And Cloudflare states that within the historical disk I/O telemetry available to it, the only activity matching the technique came from the researchers and its own engineers.

None of that makes the exposure smaller. It makes it untargeted, which is a different claim and a weaker consolation than it first sounds: an attacker who cannot choose the victim can still run the technique repeatedly and keep whatever arrives.

Where the boundary actually was

Every container here runs inside its own virtual machine under Firecracker, and the disk is presented to that machine as a single device. That is about as strong as workload isolation gets in commercial infrastructure, and it is what the product's security is usually described in terms of.

It was not the boundary that failed, because the attack never went near it.

The disks come from a Linux device mapper thin pool. Thin provisioning allocates physical storage only when a virtual disk writes to a region it has not used before, and when a container's volume is deleted its physical blocks go back to a pool shared across multiple customer accounts. The affected pools used a 64 KiB thin block and carried one option: skip_block_zeroing.

With that option set, dm-thin hands over a newly allocated block without clearing it first. So the arithmetic of the attack is simply the arithmetic of block sizes. Write 4 KiB into a fresh region and dm-thin allocates a 64 KiB physical block from the pool. The write covers 4 KiB of it. The other 60 KiB, which is 93.75 per cent of the block, can still hold whatever the previous owner left there, and a raw read of the device returns it.

One detail is worth keeping because it is what made the technique practical rather than theoretical. Reading an unmapped region returns zeroes and allocates nothing, so simply scanning a new disk finds nothing. The proof of concept instead located 64 KiB aligned regions corresponding to free space in its own filesystem and wrote a single aligned 4 KiB block into each one, forcing allocation everywhere it wanted to look.

Six hours to fix, fifteen days to make it unreachable

The response is fast and the postmortem publishes it to the minute, which is rare enough to be worth rewarding with a close reading.

Elapsed time from the researcher's report at 15:26 UTC on 4 September 2026, computed from the timestamps Cloudflare publishes.

Step	Timestamp	Elapsed from the report
Reported through HackerOne	4 Sep 15:26	zero
Incident opened, cause confirmed	4 Sep 18:45	3 hours 19 minutes
Runtime fix merged	4 Sep 21:27	6 hours 1 minute
Rollout started	4 Sep 23:15	7 hours 49 minutes
Rollout complete	7 Sep 06:13	2.6 days
Researchers confirm the technique is dead	14 Sep 10:50	9.8 days
Cleanup of cached snapshots complete	19 Sep 15:03	15.0 days
Published	24 Sep	19.4 days

The gap between line three and line seven is the part worth taking away, and Cloudflare explains it plainly rather than hiding it.

Removing the option restores the default, which zeroes blocks as they are allocated from then on. It does nothing to blocks already mapped into disks that exist. Those mappings were sitting in two places: in the disks of containers that were already running, and in each host's cache of prepared snapshots for image layers. A new container could inherit a mapping from a cached layer without allocating anything, and the residue would still be readable.

So the actual remediation was operational rather than technical. Retire every running container disk. Drain hosts during off peak hours. Restart the virtual machines. Clear every image cache built before the mitigation. That is what took the remaining fourteen days.

This generalises further than containers, and it is the reason to read this postmortem even if you will never run one. A configuration change applies to what happens next. It does not reach state that already exists. The same shape appears when an organisation enables encryption at rest and does not rewrite existing objects, tightens a permission model and does not revoke the tokens already issued under the old one, or fixes a secret generation routine and leaves every secret already generated in place. In each case the fix is minutes and the cleanup is the project.

What to do about it

The question this leaves

Cloudflare comes out of this well, and the piece should say so plainly. It fixed the mechanism the same day, published to the minute, named the researchers, worked with them on the write up, ran detection signatures across retained telemetry, and stated the limits of what that telemetry could show. The researchers come out of it well too: they built an attribution method, validated it against their own data first, reported counts and checksums rather than contents, and deleted what they recovered.

The uncomfortable part is not anyone's conduct. It is that the isolation story customers were told, and the isolation story that mattered, were about different layers of the stack. One was a microVM per container. The other was an option on a storage pool.

So the question for whatever you run on somebody else's infrastructure: when you say a workload is isolated, can you name the specific mechanism that keeps a released resource from reaching the next tenant, and did anybody check that it was switched on?