In short: On September 24, 2026, Cloudflare disclosed a vulnerability in its Containers platform (and the Sandboxes service built on it): a customer on a Workers Paid plan could recover up to 60 KB of residual data left behind by a previous tenant on the same physical host — directory structures, SQLite databases, Chromium profiles, and .env files containing secrets. The root cause was a single storage configuration setting based on Linux dm-thin. Researcher Oren Yomtov of Accomplish found the flaw on September 4 through Cloudflare's HackerOne bug bounty program; Cloudflare fixed it by September 19 and found no evidence of real-world exploitation before disclosure.
What happened
Cloudflare Containers lets customers run isolated workloads — from AI agent sandboxes to custom application code — on Firecracker virtual machines. Container disks were organized using thin provisioning: physical disk space is reserved in 64 KiB blocks only when a container actually writes to that region, not upfront, which saves space on shared hosts.
The problem was the skip_block_zeroing option: when a container was deleted, its physical blocks were returned to a shared pool later drawn on by other customers' containers — but the blocks themselves weren't zeroed out first. By writing just 4 KiB of new data into a reused block, the next tenant could read the remaining 60 KiB of leftover data at the raw disk level.
What exactly could be read
According to Cloudflare and independent researchers, 18 of 24 tested placements contained real residual data from prior workloads: directory trees, database pages including complete SQLite databases, Chromium browser profiles, and .env files — commonly used by developers to store passwords, API keys and access tokens. The vulnerability also affected Cloudflare Sandboxes, which is built on top of Containers.
An important caveat: an attacker couldn't choose a specific victim, host, or type of data in advance — they'd get a random fragment left by whoever previously occupied the same physical host. Cloudflare said a review of its disk I/O telemetry found no evidence anyone used this technique for real-world data theft before the fix shipped.
What this means for everyday users
The direct risk falls on companies and developers who ran workloads on Cloudflare Containers — their secrets and data were theoretically readable by other tenants on the same host, not on individual VPN users. But the episode is instructive more broadly: even at one of the largest cloud infrastructure providers, a single overlooked storage setting can leave other customers' passwords and tokens readable for months. If you store personal data in cloud services, it's worth periodically checking whether your credentials have surfaced in public breaches — see our guide on checking for personal data leaks.
For your own everyday traffic, the lesson is different: encryption protects your data in transit, not how a provider stores it on its own servers. Using LiMP VPN means trusting a provider to handle your traffic — which is why it matters to pick one that discloses and fixes incidents like this quickly and publicly, the way Cloudflare did here.
What to do if you used Cloudflare Containers
- Cloudflare's fix was applied automatically on September 19, 2026 — no customer action is required, but if your workload stored secrets in .env files inside the container, rotating those keys and passwords is a sensible precaution.
- Avoid storing long-lived secrets (passwords, API keys, tokens) directly in a container's or sandbox's filesystem — use a secrets manager with short-lived credentials instead.
- Regular users whose data was processed through services running on Cloudflare Containers don't need to take any specific action: Cloudflare confirmed it found no evidence of exploitation before the flaw was disclosed.
- General hygiene still applies: use unique passwords per service and a password manager, so a breach at one provider doesn't open the door to your other accounts.