Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data
- ID
- 28481
- Status
- summarized
- Published
- 25 Sep 2026, 12:49 PM
- Fetched
- 25 Sep 2026, 4:42 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 7.0
- Created
- 25 Sep 2026, 4:42 PM
- Tags
- Audience
- developersvibe_codersai_agent_userssaas_founders
What happened
Cloudflare fixed a flaw in Cloudflare Containers where shared thin-provisioned disks (64KB blocks) returned to a cross-account pool without being wiped, so a new container writing only 4KB into a reused block could read back the remaining ~60KB of a previous customer's data at the raw disk level. Reported September 4 by Oren Yomtov of Accomplish via Cloudflare's bug bounty, it was reproduced on 18 of 24 attempts and on 20 of 22 machines across four continents, recovering directory listings, SQLite databases, Chromium browser profiles, .env files and credential files. Cloudflare says it is fixed service-wide and customers need to do nothing; Cloudflare Sandboxes, marketed for running untrusted code including AI-agent-written code, was also affected.
Why it matters
If you run untrusted or AI-generated code in Cloudflare Sandboxes, the isolation boundary you were relying on had a disk-reuse gap that surfaced real .env files and complete SQLite databases from other tenants — and because the fix is entirely server-side, there is nothing to patch and no way for you to verify your own past exposure. Concretely: stop placing long-lived credentials or production database files inside sandbox working directories, and switch to short-lived per-run tokens, since leftover-block reads bypass anything your application code does.
Discussion angle
Thin provisioning skipped the default block-wipe, and a 4KB write plus a raw read exposed the other 60KB — which other 'shared pool' abstractions in your stack (ephemeral CI runners, FaaS scratch space, agent sandboxes) assume wiping you never actually verified? And practically: what belongs in a sandbox directory when a full SQLite database or .env file can be the thing that leaks?