Cloudflare fixes flaw that let one container read another customer's leftover disk data

Cloudflare has fixed a flaw in Cloudflare Containers that let a paying customer read data other customers' containers had left behind on shared servers. The company disclosed it five days after a fleet-wide cleanup finished on September 19.

The bug was reported on September 4 by Oren Yomtov of the security firm Accomplish through Cloudflare's bug bounty program. Containers runs customer code on servers shared by many accounts. Cloudflare Sandboxes, built on Containers and sold as a safe place to run untrusted code written by AI agents, was affected too.

How the flaw worked

Each container gets a writable disk built with Linux thin provisioning, which allocates storage in 64-kilobyte blocks. When a container was deleted, its blocks returned to a shared pool, and blocks were not wiped before the pool handed them to the next container.

The researchers wrote four kilobytes into each 64-kilobyte region of free space in the container's filesystem and read the raw disk back. The 60 kilobytes they never wrote still held a previous container's bytes.

In production tests they found leftover material on 18 of 24 placements and on 20 of 22 servers across four continents. Cloudflare said the blocks held directory structures, database pages and complete SQLite databases; the researchers also found Chromium profiles and credential files. Their scripts printed only counts and format checks, not file contents.

The two-step fix

Cloudflare removed the unsafe option from its storage pools fleet-wide, restoring the default zeroing of newly allocated blocks. On September 14 the researchers confirmed their proof of concept no longer worked, and the company paid a bounty the same day.

Zeroing new blocks did not clean blocks already mapped into running container disks or into each server's cache of prepared snapshots, which a new container could inherit. Cloudflare retired every running container disk and dropped those cached snapshots, spreading the work over quiet hours and clearing the image cache. The cleanup finished on September 19.

What it means

Cloudflare built detection signatures from the proof of concept and its own reproduction and checked them against retained disk-activity records. Only the researchers' and its engineers' authorized testing matched, and the company says it saw no sign that anyone else used the method. It has not said how long the unsafe setting was in place.

An attacker could not choose whose data they received, and the flaw did not let anyone change another customer's live data or take a workload offline. Accomplish calls it the sixth sandbox escape it has published since July. The researchers say the same disk setup also affected Cloudflare's Browser Run, which Cloudflare's post does not mention.