What the Cloudflare Containers Flaw Reveals About Multi-Tenant Container Security

On September 4, 2026, a security researcher at the firm Accomplish reported something unusual to Cloudflare's bug bounty program: on Cloudflare's shared Containers platform, writing just 4 KiB of data to an unused region of a brand-new container's disk could surface up to 60 KiB of leftover data from a completely different customer's earlier, deleted container. Cloudflare confirmed the flaw, finished mitigating it by September 19, and disclosed it publicly the following week — and by the time it hit Hacker News and BleepingComputer this past week, it had become one of the most-discussed infrastructure stories in tech. The bug itself is specific to Cloudflare. The underlying problem — what multi-tenant container security actually guarantees versus what it merely implies — is not, and it's worth every team running or evaluating shared infrastructure taking ten minutes to understand it.

What actually went wrong: thin provisioning without zeroing

The root cause traces back to a storage optimization called thin provisioning, which allocates physical disk blocks to a virtual volume only as data is actually written, rather than reserving the volume's full declared size up front. It's a completely standard technique, and Cloudflare's Containers platform used it the way most shared infrastructure does: when a container is deleted, the disk blocks it used get returned to a pool and handed out to the next container that needs space.

The step that was missing is the one that makes that reuse safe: zeroing out a reclaimed block before reassigning it. Cloudflare's configuration skipped that step. So when the researchers wrote a small 4 KiB payload into a new container, the underlying storage system allocated a full 64 KiB physical block to satisfy it — and only the 4 KiB they'd actually written got overwritten. The remaining 60 KiB of that block still held whatever the previous tenant had left behind. Across production tests, the researchers recovered leftover material on 18 of 24 attempts, spanning 20 of 22 physical machines across four continents, and what they pulled out included directory structures, database pages, and in some cases structurally complete SQLite databases. Cloudflare says it found no evidence the technique was exploited before the report, which is good news, but it doesn't change what the bug demonstrates about the gap between "isolated" and "isolated in practice."

Why this is a multi-tenant container security problem, not just a Cloudflare bug

It's tempting to read this as a Cloudflare-specific postmortem and move on. That would miss the point. Thin provisioning without guaranteed block zeroing is an implementation choice, not a Cloudflare-only architecture — any shared container platform, serverless runtime, or multi-tenant PaaS that reclaims and reuses disk blocks between customers has to get this exact detail right, and it's the kind of detail that doesn't show up in a feature comparison or a pricing page. Multi-tenant container security lives or dies in decisions like this one: does the platform zero blocks before reuse, or does it rely on the assumption that customers won't go looking? Cloudflare failed that test badly enough that a single 4 KiB write could pull back another company's data.

This matters more than it would have three years ago because so much infrastructure has quietly moved toward shared, ephemeral compute — containers, serverless functions, edge runtimes — precisely because it's cheaper and faster to provision than dedicated, single-tenant infrastructure. That trade is usually the right one. But every team making it is implicitly trusting the platform's multi-tenant container security model, often without ever having asked the platform directly what that model actually is.

The questions to ask before you trust a platform with your data

Most vendor security questionnaires ask about encryption in transit and at rest, access controls, and compliance certifications — all reasonable, none of which would have caught this bug. Encryption at rest protects data from someone stealing a physical disk; it does nothing if the platform itself hands your old, deleted data to its next customer as part of normal operation. The questions that actually probe multi-tenant container security are more specific: does your storage layer zero or otherwise sanitize reclaimed blocks before reassigning them to a different tenant? Are volumes for different customers ever backed by the same underlying physical disk, or is isolation enforced at the hypervisor or hardware level? What's your disclosed incident history, and how fast did you patch the last one?

Most vendors won't have a crisp answer to the first question, because most engineering teams building shared infrastructure haven't had to think about it until a researcher forces the issue. That's not a reason to panic about every container platform you use — it's a reason to ask the question explicitly for anything handling data you'd actually mind seeing leaked, rather than assuming "it's containerized" implies "it's isolated."

Where dedicated infrastructure still earns its cost

This is also a useful moment to revisit a trade-off we walk clients through constantly: shared, multi-tenant compute is cheaper and faster to stand up, but it's borrowing someone else's isolation guarantees, and those guarantees are only as good as the platform's least-examined implementation detail. Dedicated infrastructure — your own EBS-backed volumes on your own EC2 instances, a VPC with no shared tenancy at the storage layer — costs more and moves slower to provision, but it removes an entire category of risk: there's no other customer's leftover data to accidentally receive, because there's no other customer sharing your disks in the first place.

We're not suggesting every workload needs dedicated infrastructure — that would be as reflexive as assuming every shared platform is fine by default. The decision point is what's actually stored on disk: session caches and ephemeral build artifacts are a very different risk profile than customer PII, payment data, or anything under a compliance obligation. For the former, a well-run shared container platform is a completely reasonable choice. For the latter, the extra cost of dedicated, single-tenant storage buys you out of exactly the failure mode Cloudflare just patched — and that's worth pricing in before an incident, not after one.

Questions worth putting in writing to a platform vendor

Generic security questionnaires miss this class of problem. These questions are specific enough to get a real answer, or to show that nobody has asked before.

• Are storage blocks zeroed or cryptographically erased before they are reassigned to another customer?
• How is isolation tested between tenants, and how often? Ask about independent testing and bug bounty coverage.
• What happens to data when a container, volume or function is deleted? Is deletion immediate, and is it verifiable?
• Is there a dedicated or single-tenant option for sensitive workloads, and what does it cost?
• How are vulnerabilities disclosed to customers? Timelines and communication matter as much as the fix.

Classify what you put on shared infrastructure

What we'd actually recommend

Don't treat this as a Cloudflare-specific story to file away. Go back to whatever shared container or serverless platform you're actually running production workloads on, and ask them directly whether reclaimed disk blocks are zeroed before reassignment to a different tenant — most vendors have never been asked and may not know the answer off the top of their head, which is itself useful information. For anything storing regulated or sensitive customer data, default to dedicated, single-tenant storage rather than assuming a shared platform's marketing language about "isolation" covers this specific case. And if you're currently evaluating platforms for a new build, add "how do you handle disk block reuse between tenants" to the same short list of questions you'd ask about encryption and access control — it's cheap to ask up front and expensive to find out the hard way that nobody on either side had thought to ask it.