The Hidden Attack Surface: Residual Cloud Data and AI-Directed Malware

Security teams are accustomed to inventorying what is visible: hosts, ports, APIs, identities, packages, vulnerabilities, and known command-and-control infrastructure.

Two technical disclosures published this week show how much risk can live outside that inventory.

Cloudflare described a cross-tenant vulnerability in which a newly created container could recover fragments of data left by earlier workloads. Cisco Talos released an open-source toolkit for detecting AI-integrated malware through the prompt templates, provider endpoints, orchestration logic, and other “cognitive artifacts” its authors leave behind.

The two cases operate at very different layers. One concerns Linux storage allocation. The other concerns model-assisted malware. But they point to the same engineering lesson:

The real attack surface includes hidden state beneath the abstraction—and behavioral residue above it.

A container may be gone while its data remains. A malware sample may change its binary or infrastructure while its AI integration still leaves recognizable traces.

When Deleting a Container Does Not Delete Its Data

On 24 September 2026, Cloudflare published a detailed account of a vulnerability affecting Cloudflare Containers and Cloudflare Sandboxes. The issue had been responsibly reported on 4 September by Oren Yomtov of Accomplish.

Cloudflare runs customer containers inside dedicated Firecracker virtual machines. Each workload receives a writable root disk backed by Linux device-mapper thin provisioning, or dm-thin.

Thin provisioning allocates physical storage only when a virtual disk writes to a previously unused region. When a container was deleted, its physical blocks returned to a storage pool used by workloads from multiple customer accounts.

That design is not inherently unsafe. The critical detail was one configuration option:

skip_block_zeroing

With block zeroing disabled, a newly allocated block was not cleared before being exposed to its next owner.

The affected pools used 64 KiB allocation blocks. The researchers found that they could write a 4 KiB fragment into a newly allocated block and then read the remaining 60 KiB. Because only the written portion had changed, the rest could contain data from a previous tenant.

This was not a theoretical edge case. Across six production placements, the researchers observed residual material on 18 of 24 placements and 20 of 22 underlying nodes. The recovered structures included filesystem directory data, database pages, and structurally complete SQLite databases.

The technique could not select a particular customer, workload, host, or file. It could not access another tenant's active disk or modify an active workload. Recovery depended on scheduling and which released blocks were reassigned.

Those limitations reduce the attacker's precision. They do not remove the tenant-isolation failure.

Read Cloudflare's complete technical account: How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers.

Why the First Fix Was Not Enough

Cloudflare's remediation is particularly instructive.

The immediate fix was to remove skip_block_zeroing, restoring the default behavior of clearing newly allocated blocks. The researchers independently confirmed that their proof of concept stopped working.

But changing the configuration protected only future allocations. It did not sanitize blocks already mapped into running container disks or cached snapshots used for image layers.

Cloudflare therefore had to retire existing container disks, drain hosts, restart virtual machines, and clear image caches so that the affected state was recreated with zeroed allocations. Fleet-wide cleanup of pre-mitigation snapshots was completed on 19 September.

Cloudflare also derived a detection pattern from the exploit: a small write that allocated a larger block, followed by reads substantially exceeding the amount written. It searched retained disk-I/O telemetry and found only activity attributable to the researchers and Cloudflare's authorized validation. The company reports no evidence of malicious exploitation.

This is a good incident-response lesson. A configuration change may stop the triggering condition without eliminating the vulnerable state that already exists.

Effective remediation must answer three different questions:

Has the unsafe behavior been stopped?
Has previously exposed state been destroyed or rebuilt?
Can telemetry distinguish historical exploitation from legitimate activity?

Stopping at the first question creates a technically patched but incompletely remediated system.

Ephemeral Infrastructure Has Persistent Consequences

Containers, serverless workers, CI runners, development sandboxes, and temporary analysis environments are designed to feel disposable. That disposability can create a false sense of security.

Deleting the logical workload does not necessarily erase:

Thin-provisioned storage blocks
Snapshots and cached image layers
Temporary files on the host
Memory-backed secrets and credentials
Build caches and package-manager caches
Logs, traces, and crash dumps
Object-storage versions
Attached volumes or orphaned mappings

The security boundary is therefore larger than the container or virtual machine. It includes every resource that stores, reuses, snapshots, schedules, or reconstructs the workload.

For platform teams, this means testing tenant isolation at the lifecycle boundaries—not only while two tenants are running simultaneously. Provisioning, deletion, reassignment, snapshot reuse, restore, and host replacement are all security-sensitive transitions.

A New Detection Surface for AI-Integrated Malware

Two days before Cloudflare's disclosure, Cisco Talos released CAIRN, the Cognitive Artifact Intelligence Research Network.

CAIRN is an open-source research toolkit for finding and organizing malware that incorporates AI systems. Its central observation is simple: integrating a model into malicious tooling leaves artifacts.

Those artifacts can include:

Model-provider API endpoints
API-key prefixes
Hard-coded system prompts
Agent tool-call syntax
Local inference runtimes such as Ollama or llama.cpp
Orchestration and voting logic
Natural-language instructions intended to mislead AI-based analysis
AI terminology appearing alongside offensive capabilities

CAIRN performs metadata-first hunting. It can work from VirusTotal metadata, extracted strings, sandbox behavior, antivirus labels, Sigma results, and related infrastructure without downloading or executing the underlying binary.

The toolkit combines three levels of YARA classification with semantic clustering and relationship graphs. Primitive artifacts establish that AI-related material is present. Behavioral combinations add context. Higher-confidence rules associate samples with confirmed operational families.

Talos is careful about the limitations. AI-related strings are noisy. PyInstaller packages may expose unused dependencies. Benign applications increasingly contain model libraries and provider endpoints. Embedding similarity can identify an interesting cluster, but it cannot establish attribution.

CAIRN treats semantic similarity as a source of leads, not conclusions. Reverse engineering and analyst validation remain necessary.

Read the methodology and inspect the code: Introducing CAIRN and the CAIRN repository.

CLOSEDQUORUM: Models as Command-and-Control Infrastructure

Using CAIRN, Talos identified a Windows implant it calls CLOSEDQUORUM.

Traditional malware often receives instructions from an attacker-controlled command-and-control server. CLOSEDQUORUM's analyzed architecture instead queries up to four commercial model providers: DeepSeek, Qwen, Mistral, and Google Gemini.

Each model receives host context and selects from a constrained set of actions. The results are combined through plurality voting, and the winning action is executed. Implemented capability handlers include credential theft, persistence, and process injection.

This does not mean a language model invents arbitrary attacks from scratch. The malware author has already defined the available capabilities and the schema that model responses must follow. The models operate as decision engines inside an attacker-created execution framework.

The approach offers several potential advantages to an attacker:

Tactical choices can continue without an operator online.
Several providers create resilience against refusal, timeout, or malformed output.
Legitimate AI-provider domains replace a unique C2 endpoint.
Attack logic can adapt to basic host context within predefined boundaries.

It also introduces new weaknesses:

Provider refusals and rate limits can interrupt operation.
Model traffic creates detectable network patterns.
Structured prompts and schemas may remain in the binary.
API credentials may be recovered or revoked.
Predictable voting and fallback behavior can be studied.
The malware still performs conventional, detectable actions such as LSASS access, injection, and persistence.

The most important qualification is that CLOSEDQUORUM is not a confirmed active campaign. Talos verified its architecture through static analysis and related development artifacts, but the public distribution build contains placeholder API keys and a dummy webhook. Talos did not observe a complete end-to-end execution or confirm deployment in the wild.

It should be treated as a technically documented architecture and an early warning—not proof that autonomous multi-model malware is already operating at scale.

Read the full analysis: The Closed Quorum: Inside the first reported autonomous AI C2 implant.

Why Domain Blocking Will Not Be Enough

Blocking every connection to an AI provider is neither realistic nor particularly effective. The same endpoints support legitimate development tools, business applications, assistants, and security products.

The stronger detection opportunity is behavioral correlation.

A legitimate desktop application might contact one model provider. Far fewer legitimate processes should contact several competing model APIs within a short period while also reading LSASS, dumping browser credentials, injecting into a suspended process, creating WMI persistence, or posting data to a Discord webhook.

Defenders should therefore connect four kinds of evidence:

Process identity: Which binary initiated the request, and is it signed or expected?
Model interaction: Which providers or local runtimes did it contact?
Endpoint behavior: Did it access credentials, inject code, or create persistence?
Exfiltration behavior: Did the same process communicate with webhooks, storage services, or unusual destinations?

Any one signal may be benign. Their sequence can be distinctive.

What Engineering and Security Teams Should Do

These disclosures suggest several practical actions.

For cloud and platform infrastructure:

Review thin-provisioning options and confirm that reused allocations are initialized before exposure.
Test data remanence across workload deletion, host migration, image-cache reuse, and snapshot restoration.
Include caches and already mapped volumes in remediation plans.
Retain enough low-level telemetry to reconstruct allocation and reuse behavior.
Treat ephemeral CI and analysis environments as potential holders of durable secrets.

For endpoints and security monitoring:

Inventory applications, agents, and malware-analysis tools that legitimately contact AI providers.
Alert on unexpected processes containing provider credentials, prompt templates, or offensive tool-call schemas.
Correlate multi-provider traffic with credential access, injection, persistence, and webhook activity.
Preserve prompt and orchestration artifacts during malware analysis; they may provide family-level or campaign-level pivots.
Treat instructions addressed to an AI scanner as possible analysis-evasion content, not as commands to follow.

For incident response:

Distinguish stopping the exploit from removing the vulnerable historical state.
Require evidence that rebuilt resources no longer expose test markers.
Record model-provider traffic alongside process and endpoint telemetry.
Avoid claiming AI-enabled attribution from metadata or semantic similarity alone.

The Abstraction Is Not the Boundary

The cloud promises disposable workloads. AI services promise intelligent decisions behind ordinary APIs. Both abstractions are useful—and both can hide security-relevant state.

Cloudflare's disclosure shows that isolation can fail below the virtual-machine boundary, in the details of block allocation and snapshot reuse. CAIRN shows that model-assisted malware can be detected above the binary layer, through the cognitive and network artifacts required to make AI operational.

The broader lesson is to stop defining the attack surface only by the objects presented to users and administrators.

Security teams need to examine what those objects reuse, what they leave behind, what they contact, and what sequence of behavior results.

At Funway Interactive, we build production software and test the assumptions underneath it—from application logic and identity boundaries to cloud infrastructure and AI-enabled workflows. If your organization is introducing multi-tenant infrastructure, autonomous agents, or AI-connected applications, we can help threat-model the complete system and test whether its security boundaries survive real lifecycle transitions.

Talk to Funway Interactive about penetration testing and security engineering.