- Sources: report, discussion
- Summary: A shared storage pool was configured to skip zeroing reused 64 KiB blocks, so when a container's thin volume was deleted its physical blocks went back to a pool serving multiple customer accounts, and writing only 4 KiB into an unused region of a new container's disk allocated a reused block and left the remaining 60 KiB readable. Researchers found residual material on 18 of 24 container placements and across 20 of 22 underlying nodes tested, including directory structures, database pages, and structurally complete SQLite databases, but their scripts returned aggregate counts rather than disk contents, so no real customer data was exposed in the evaluation, and Cloudflare states it found no evidence in logs, telemetry, or historical data that customer data was exposed by this method. Oren Yomtov reported it through HackerOne on 2026-09-04, and Cloudflare removed the setting, retired existing container disks and cleared cached snapshots that could hold old mappings, finishing on 2026-09-19, and states customers need take no action.
- Why it matters: The isolation boundary that multi-tenant serverless platforms are sold on failed here on a storage configuration setting rather than a code defect, so anyone running multi-tenant thin-provisioned storage should check whether block reuse is zeroed.
- Follow-up: Cloudflare's blog index lists a Containers disclosure post dated 2026-09-24 that no slug resolved to automated fetch, so watch for that vendor post becoming reachable, and for further multi-tenant findings from Accomplish, credited with this report and with the SharedRoot Claude Cowork sandbox escape.
send feedback on this story