Cloud computing runs on an implicit promise: many customers can share infrastructure as long as each customer remains strictly confined to their own environment.
Before the vulnerability: what does Cloudflare actually do?
Cloudflare operates one of the large global networks that sits between Internet users and the applications they access. For businesses and developers, it can accelerate websites through a CDN, provide authoritative DNS, filter DDoS attacks and malicious traffic with application security services, route traffic, secure workforce access with Zero Trust products and move content closer to users through its global edge network.
Cloudflare is no longer only the shield placed in front of an origin server. Through its Developer Platform, it also lets teams run code with Workers, use managed storage services and now execute containerised workloads without operating the underlying physical machines themselves.
That is why this incident matters. When one platform can protect, accelerate and directly execute parts of an application, a failure in tenant separation is no longer an obscure infrastructure detail. It reaches the trust boundary on which the service is built.
On 24 September 2026, Cloudflare disclosed that a vulnerability in Containers and Sandboxes had broken that boundary under specific conditions. A customer with a Workers Paid account could recover residual data from disk blocks previously used by other containers on the same underlying host.
Cloudflare says the issue has been fully remediated and that the historical telemetry available to the company showed no evidence of malicious exploitation. Customers are not required to take any action.
That does not make the incident uninteresting.
The important part is not simply that Cloudflare had a bug. It is that a modern workload can be strongly isolated at one layer while another layer quietly weakens the overall boundary.
The cloud does not share your application. It shares infrastructure. Security lives in everything that separates the two.
A microVM per workload is not enough if storage forgets badly
Cloudflare Containers runs workloads inside lightweight virtual machines based on Firecracker. That gives every workload a virtualization boundary rather than relying only on traditional container isolation.
On paper, that is a strong design.
The weakness reported by Oren Yomtov and the Accomplish security team sat underneath that boundary, in the way physical storage blocks were recycled.
Cloudflare used Linux device-mapper thin provisioning, or dm-thin, to provide each container with a writable root disk. Physical storage was allocated in 64 KiB thin blocks. When a volume was deleted, its blocks returned to a pool that served workloads from multiple customer accounts.
The affected pool configuration used skip_block_zeroing.
That meant a physical block could be reassigned without its previous contents being fully cleared first.
If the new workload wrote only 4 KiB into a reused 64 KiB block, the remaining 60 KiB could still contain bytes left by the previous owner.
The attack was therefore not about breaking into another customer's virtual machine. It abused something quieter: storage that had not been fully sanitised before reuse.
The small write that turned a storage bug into a tenant-boundary failure
Simply reading an unmapped part of the thin device did not reveal old data because dm-thin returned zeroes.
The researchers instead triggered allocation by writing a small 4 KiB chunk into a selected 64 KiB region and then reading the entire physical block.
The unwritten remainder could expose residual bytes.
During controlled testing, the researchers observed foreign residual material on 18 of 24 placements and 20 of 22 underlying nodes. They identified structures including directory metadata, database pages and structurally complete SQLite databases.
Those figures do not mean that 18 out of 24 customers were compromised. The researchers could not select a particular victim, account, workload or host, and residual data was not guaranteed to be present.
But the confidentiality boundary between tenants could be crossed.
For multi-tenant infrastructure, that boundary is the product.
Cloudflare had to fix two states, not one
The first mitigation was straightforward: remove skip_block_zeroing so that newly allocated blocks are cleared before being exposed to another workload.
That stopped new allocations from leaking old contents.
It did not automatically clean blocks that had already been mapped into running container disks or cached image snapshots. Cloudflare therefore also drained hosts, recreated affected disks and removed pre-mitigation cached snapshots.
The initial runtime mitigation was fully rolled out by 7 September. Cleanup of pre-mitigation cached snapshots was completed on 19 September. The technical disclosure followed on 24 September.
That sequence matters because stopping new exposure and eliminating old state are two different jobs.
In security, fixing the lock while leaving yesterday's keys under the mat is not a complete remediation.
Firecracker is not the villain, and containers are not automatically unsafe
It would be easy to read the incident as proof that containers are inherently dangerous or that Firecracker failed.
That would miss the architecture.
Firecracker is specifically designed to provide strong isolation for multi-tenant workloads. Cloudflare says each container ran in its own dedicated microVM.
The leak came from storage underneath that boundary.
For architects, the lesson is broader: secure architecture is not a single secure component in the middle of a diagram. It is a chain.
CPU, memory, hypervisor, network, storage, caches, secrets, orchestration, logs and backups all participate in the final isolation model. One reused resource can weaken the property that every other layer was trying to protect.
A system is only as trustworthy as the boundaries between its components.
Why this matters even if you do not use Cloudflare Containers
For many small African engineering teams, managed cloud services are what make modern infrastructure affordable to operate. They reduce the need to hire a large platform team before the product has even found its market.
That is sensible.
The wrong conclusion from this incident would be: self-host everything.
A small company that leaves a well-operated managed platform to run its own hypervisors, patching, backups, secret management and monitoring does not automatically become safer. It simply takes ownership of more failure modes.
The useful conclusion is to stop confusing infrastructure outsourcing with risk disappearance.
When using a multi-tenant platform, teams should still know what data enters the workload, what persists, which secrets are reachable, how environments are segmented, and what happens if a provider isolation boundary is imperfect.
Three questions worth asking before the next deploy
First: does the workload handle information whose exposure would be unacceptable even in a low-probability cross-tenant incident?
Second: if the filesystem leaked, would it expose credentials that unlock other systems?
Third: is the cloud platform one layer in a segmented architecture, or would compromise of that layer immediately expose everything else?
These questions are not bureaucracy. They are how a team keeps convenience from becoming a single point of failure.
Cloudflare's response was useful. The architecture lesson remains.
Cloudflare received the report on 4 September, opened an incident within hours, rolled out mitigations, validated the fix with the researchers and later published a detailed technical explanation.
That level of transparency is valuable because it lets engineers study the mechanism rather than consume a vague security notice.
But a good incident response does not erase the design lesson.
We increasingly build on layers we cannot see: serverless runtimes, managed containers, distributed databases, AI agents and edge platforms. The dashboard is intentionally simple because the infrastructure underneath is not.
That simplicity is the product.
It is also where assumptions hide.
Cloud computing removes a large amount of machine management. It does not remove the need to understand where our trust boundaries begin and end.