When Accomplish’s researchers started poking at Cloudflare Containers, they weren’t chasing a splashy remote exploit. They found leftover disk. Files from a previous workload still sitting there after the container was gone. Another tenant’s residue on a volume that should have started blank. That is a cybersecurity problem with no malware dropper, no brute-force spray, and no firewall alert that tells you anything useful. The last job just never finished leaving.

The Last Tenant’s Files Were Still on Disk

Cloudflare’s own write-up is unusually direct. External researchers at Accomplish showed that a Containers environment could expose residual disk data from the workload that ran before yours. You spin something up. You assume you got a clean slate. The previous tenant’s leftovers were still readable.

Shared compute sells you isolation. Hypervisors, cgroups, namespaces, overlay filesystems. You already pay for that story. Residual disk is the part vendors used to file under “deleted.” Deleted in the control plane is a flag. Unreadable on the block device is a different property. If the next container can see the last container’s files, your tenancy model is a slide deck.

On a busy node, teardown is a race. The orchestrator marks the task complete, the overlay unmounts, the next pod schedules. If the block device or the scratch volume is reused faster than a discard or a re-key, you inherit whatever the last job wrote. That is a scheduling problem with a data-leak outcome.

Cloudflare investigated, published, and remediated. Credit where it’s due. Treat the finding as a pattern. Anyone running containers on shared hosts, CI runners, GPU pools, or serverless disk that outlives the request has the same question: what happens to the blocks after teardown?

This is where threat-protection consoles go quiet. They watch packets and processes. They do not watch whether a mount still holds someone else’s export. Your SOC’s threat detection is trained on lateral movement and ransom notes. Cross-tenant residue looks like a boring filesystem. Until a customer file shows up in a neighbor’s instance.

Shared-Runtime Cybersecurity Starts After the Process Exits

The same week, the market told on itself. Kontext Security raised $4 million to put runtime controls around AI agents; visibility into what an agent actually does once it’s live, not what the prompt claimed it would do. That check exists because teams got tired of trusting isolation at start time. If a container can inherit a disk, an agent can inherit a session, a token, or a directory tree it was never supposed to see.

You already watched a version of that happen. An OpenAI agent went looking for public spending data on an Australian government Medicare statistics portal and found non-public files instead. Then reporting took months. The agent used a path your inventory still labels public. Your cyber security review probably filed that host as a stats site. The agent treated it as a filesystem.

Put those two incidents on the same whiteboard. Cloudflare’s bug is leftover storage on a shared runtime. The government portal is leftover exposure on a host that advertised a public face. Kontext is the vendor class that shows up when teams admit they cannot see what a workload does between started and stopped. You scoped the live process and ignored what remains when the process is gone, or what the process can still reach because nobody mapped the leftover surface.

A firewall still matters. It will not save you here. Packet filters do not wipe disks. They do not shrink a stats portal’s file tree. Defense in depth for shared runtimes means you treat storage, identity, and teardown as peer controls, not extras you schedule after the network diagram looks pretty.

Make Teardown a Control You Can Audit

Stop arguing about whose cloud this is. You can test leftover disk in any environment you actually run.

Do the inventory this week. List every shared runtime: container hosts, build agents, notebook platforms, GPU schedulers, functions with attached storage. Write one sentence per platform that states the wipe guarantee. If the sentence is “the vendor deletes the instance,” you do not have a guarantee. Demand the mechanism. Block discard, volume re-encryption, a new ephemeral disk per job, or cryptographic erase. If you cannot get a mechanism, assume residue and stop mixing tenants on that pool.

Then put a canary on disk. A unique filename and a unique string, written by job A. Tear the job down the way production does, not the way the demo does. Start job B on the same class of host. Search for the canary. Finding it means you have a cross-tenant incident. Pull the host from the pool. Snapshot it for forensics. Rotate anything that could have lived on that volume: secrets, tokens, customer exports, SSH keys, package-registry tokens, cloud credentials.

Keep doing security hardening around teardown the same way you already do it around image provenance. New disk, or a freshly encrypted disk, per tenant. No volume reuse across customers. Snapshots are copies of residue, so lock who can create and attach them. CI runners get one-shot VMs, not a sticky local cache on a hot host. If you must cache, cache on storage you encrypt with a job-scoped key you destroy on exit.

Give incident response a playbook that does not open in the SIEM. Cross-tenant disk is a disclosure event. You will need a timeline of which tenants landed on which host, which volumes were attached, and what data classes those jobs handled. Practice that pull. Your IR team can hunt brute-force against SSH all day and still miss a leftover export that never generated an auth failure.

Keep defense in depth honest. Network policy. Identity scoped to the job. Disk that dies with the job. Logging that records volume attach, snapshot, and host reuse. If threat detection cannot see those control-plane events, you are blind in the one place this failure shows up.

You will be tempted to file this under vendor risk and wait for the next blog post. Don’t. The Accomplish finding landed because someone looked at leftover blocks. Your users, your agents, and your CI jobs are already looking at leftover paths. The only question is whether you looked first.

Sources

• How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers
• OpenAI agent breached Australian government site, took months to report it
• Kontext Security Emerges With $4 Million for AI Agent Runtime Controls