AI Worm Adapts Its Attacks and Spreads Across Windows, Linux, and IoT Devices

Security researchers have demonstrated an AI-powered computer worm that can examine different systems, select suitable attack methods, and replicate across a network without continuous human control.

The proof-of-concept worm spread across Windows, Linux, and Internet of Things devices in a contained laboratory. It used a locally hosted large language model to reason about targets and generate attack strategies based on reconnaissance data.

The research represents a significant step beyond traditional worms with fixed exploit libraries. However, it does not show malware creating reliable zero-day exploits or adapting to real-world defensive systems at internet scale.

Researchers demonstrated an adaptive AI worm in a lab

The AI Agents Enable Adaptive Computer Worms study describes a proof-of-concept that combined AI reasoning, network exploitation, self-replication, and stolen computing resources.

Researchers from the University of Toronto, Vector Institute, University of Cambridge, and ServiceNow tested the system in an isolated virtual network containing 33 hosts.

The test environment included common operating systems, services, configurations, and vulnerabilities that organizations could encounter in corporate networks.

Research detail	Reported result
Test environment	Isolated 33-host network
Systems included	Windows, Linux, servers, workstations, and IoT devices
Number of experiments	15 independent runs
Duration	Seven days per experiment
Average vulnerabilities identified	31.3
Average hosts exploited with elevated access	23.1
Average hosts receiving a replicated worm copy	20.4
Maximum replication depth	Seven generations

How the AI-powered worm works

A conventional worm carries a predetermined collection of exploits, credentials, and propagation rules. It scans for systems that match those rules and copies itself when an attack succeeds.

The experimental AI worm instead placed an agentic reasoning system around its propagation process. It collected information about a target, considered possible weaknesses, attempted an attack, and revised its approach when necessary.

Its operation included the following stages:

1. Discover reachable devices and services.
2. Collect information about the target’s software and configuration.
3. Identify possible vulnerabilities or weak credentials.
4. Generate or select a target-specific attack strategy.
5. Attempt to gain access and elevate privileges.
6. Transfer a copy of the worm to the compromised device.
7. Launch a new agent instance that repeats the process.

The system used an open-weight language model that could run locally on one graphics processor. This removed the need to contact a commercial AI provider for every reasoning request.

Compromised computers supplied AI processing power

The worm’s architecture allowed infected machines to support its continued operation. A compromised system with a suitable GPU could host the language model and provide reasoning services to other infected devices.

Lower-powered systems, including IoT devices, could extend the worm’s network reach while sending more complex reasoning tasks to an infected GPU host.

This design could make centralized disruption harder because the worm would not depend on one attacker-controlled AI service. Blocking a commercial model API or suspending an account would not necessarily stop locally hosted copies.

Compromised device type	Possible role
GPU-equipped computer	Runs the local language model and processes reasoning requests
Server or workstation	Provides network access, credentials, storage, and propagation opportunities
Low-powered IoT device	Extends network reach and contacts a remote reasoning node

The worm used known weaknesses, not newly invented zero-days

The research does not establish that an AI system can reliably discover and weaponize unknown vulnerabilities during an outbreak.

The worm primarily exploited common weaknesses placed in the test network. These included known vulnerabilities, weak credentials, exposed services, and configuration errors.

It also exploited three vulnerabilities disclosed in 2026, after the base model’s training cutoff. The agent read public advisory information at runtime and converted that information into working attack strategies inside the test environment.

This result suggests that an autonomous system could reduce the time between public disclosure and automated exploitation. It does not mean that the model independently discovered those vulnerabilities.

A more advanced Intelligent Worm remains partly hypothetical

A separate analysis of the Intelligent Worm threat model considers what could happen if malware continually regenerated its infection methods after defenders blocked its earlier techniques.

In that scenario, the worm would follow an observe, plan, act, and verify cycle. It could examine why an attack failed, generate another candidate capability, test it, and update its propagation module.

This would differ from a modular worm that downloads new exploits created by human operators. The proposed worm would attempt to close more of the adaptation loop itself.

Worm type	How it adapts	Human involvement
Traditional worm	Uses exploits embedded before release	Humans must create a new version
Modular worm	Downloads new attack modules from command infrastructure	Humans usually develop the modules
AI-assisted worm	Uses AI to select or generate target-specific strategies	Can operate autonomously for parts of the attack
Fully adaptive Intelligent Worm	Regenerates and validates capabilities as defenses change	Little or no human involvement in propagation

Generated exploit code remains unreliable

Large language models can produce scripts, analyze error messages, and suggest attack paths. They can also generate incorrect commands, invalid code, and strategies that do not match the target environment.

An adaptive worm would need a reliable way to test generated code before deploying it. Otherwise, failed attempts could crash services, reveal the infection, or damage the worm itself.

Creating an accurate test environment for an unknown target presents another challenge. The malware may not know the exact software build, security configuration, network controls, or dependencies running on the destination.

• Generated code may contain syntax or logic errors.
• A working proof of concept may fail against a different software build.
• Testing can consume substantial processing power.
• Repeated probes can trigger security alerts.
• Incorrect exploitation attempts can crash the target.
• Malware may struggle to reproduce the target environment safely.

These limitations make a fully autonomous worm that reliably produces new exploits in real time less practical than a system that adapts attacks involving known vulnerabilities and misconfigurations.

A hybrid operation may pose the nearer-term threat

A more realistic attack could combine autonomous malware with centralized infrastructure and human assistance.

Infected devices could collect software versions, network details, error messages, and authentication results. They could send that information to a more powerful AI system or a human-controlled operation for analysis.

The attackers could then return updated modules or instructions to the infected network. This model would preserve much of the adaptive benefit without requiring every worm copy to perform advanced exploit research independently.

Centralized support would also give defenders a possible disruption point. Security teams could identify, block, or seize the infrastructure used to coordinate infected devices.

Adaptive worms may spread more slowly than traditional outbreaks

Traditional worms can replay the same exploit at high speed. Some historic outbreaks infected large numbers of systems within minutes or hours.

AI reasoning takes more time because the agent must collect information, make repeated model calls, create a strategy, execute commands, and evaluate the result.

In the laboratory research, the proof-of-concept needed about five days to reach half of the test network. Faster models and hardware could shorten that window, but adaptive reasoning still creates additional work compared with replaying a fixed exploit.

Propagation approach	Speed advantage	Main limitation
Fixed exploit replay	Can attack many hosts quickly	Fails when systems do not match the embedded exploit
AI-guided propagation	Can tailor attacks to different targets	Requires time and computing resources for reasoning
Slow and stealthy spread	May avoid simple rate-based alerts	Reaches fewer systems during the same period

Behavior still gives defenders an advantage

An AI worm can rewrite code and vary its attack sequence, but it must still perform actions that defenders can observe.

It needs to discover hosts, scan services, test credentials, open remote sessions, transfer files, create processes, and establish communication between infected systems.

Running a language model on a compromised device may also create unusual CPU, GPU, memory, storage, and network activity.

Potential detection signals include:

• Unusual internal network discovery from ordinary endpoints
• Repeated connection attempts across many ports and systems
• Credential reuse across unrelated hosts
• Automated installation of SSH keys or remote access tools
• Unexpected processes opening network listeners
• Large increases in GPU or processor use
• Model files appearing on systems that do not run approved AI workloads
• Reasoning requests moving between internal devices
• New persistence mechanisms and scheduled tasks
• Repeated testing of commands, scripts, or payloads

Network segmentation can slow self-propagating malware

The experimental worm operated in a largely flat test network where systems could reach one another. Many real organizations also maintain broad internal connectivity that can support lateral movement.

CISA’s microsegmentation guidance explains that dividing networks into smaller security zones can reduce the attack surface and limit lateral movement.

Segmentation prevents one compromised workstation from automatically reaching every server, management interface, development system, and IoT device.

Organizations should control traffic between segments according to operational needs instead of allowing unrestricted internal communication.

Zero trust can restrict the worm after initial access

Network location should not automatically grant trust. A device that sits inside the corporate network may already belong to an attacker.

The NIST Zero Trust Architecture guidance recommends making authentication and authorization decisions for users, devices, and resources rather than relying on a trusted internal perimeter.

This approach can reduce the permissions and systems available to an infected host. It also makes stolen credentials less useful when access decisions consider device identity, context, and policy.

Security control	Effect on an adaptive worm
Microsegmentation	Reduces the number of systems reachable from each infected host
Least privilege	Limits the accounts, files, and administrative actions available
Multifactor authentication	Reduces the value of stolen passwords
Application allow-listing	Blocks unauthorized tools and model runtimes
Egress filtering	Restricts communication with external or internal reasoning infrastructure
Behavioral monitoring	Detects scanning, lateral movement, and unusual resource use

Organizations should prepare automated containment controls

Response speed matters during a self-propagating attack. Manual investigation may not isolate systems quickly enough when each compromised device begins targeting others.

Security teams should define conditions that automatically restrict or quarantine a device when its behavior matches worm-like propagation.

Useful circuit breakers can include:

1. Rate limits for internal connection attempts.
2. Automatic isolation after broad network scanning.
3. Temporary credential suspension after abnormal reuse.
4. Blocking unauthorized remote administration protocols.
5. Quarantining systems that transfer executables to multiple hosts.
6. Restricting unexpected GPU workloads and model-serving processes.
7. Disabling communication between compromised network segments.
8. Revoking tokens and sessions associated with affected devices.

Patching remains essential despite adaptive attacks

An adaptive worm does not make software updates irrelevant. Every patched vulnerability removes one available path and forces the malware to spend more time searching for alternatives.

The research also suggests that organizations may face shorter windows between vulnerability disclosure and automated exploitation. Security teams should prioritize internet-facing systems, remote access products, identity infrastructure, and widely reachable internal services.

Automated patch verification can help organizations confirm whether updates actually removed the vulnerable condition. Asset inventories remain equally important because teams cannot patch systems they do not know exist.

The proof of concept had deliberate safety limits

The researchers designed their worm to demonstrate feasibility rather than create operational malware. They withheld technical details that could materially help attackers reproduce the system.

The prototype did not encrypt its communications, hide forensic evidence, use polymorphic code, or attempt advanced evasion. It also contained controls intended to prevent it from leaving the isolated laboratory.

The adaptive computer worm research remains under academic peer review. Its results should therefore receive further scrutiny and independent validation.

The threat is real, but the strongest claims need caution

Researchers have now shown that an AI agent can support autonomous worm propagation across a mixed network containing realistic weaknesses.

They have not shown an unstoppable worm that invents zero-days, bypasses every defense, or mutates instantly after each security update.

The broader Intelligent Worm analysis also concludes that a maximally capable autonomous version remains beyond current dependable AI capabilities. The more immediate risk comes from partial implementations that automate reconnaissance, known-vulnerability exploitation, credential attacks, and lateral movement.

Organizations do not need speculative defenses to prepare. Fast patching, strong identity controls, behavioral monitoring, limited privileges, and well-designed segmentation can all reduce the worm’s ability to reproduce.

CISA’s Zero Trust microsegmentation recommendations can help organizations reduce connectivity between workloads and contain compromised systems.

The NIST zero trust framework also provides a foundation for removing implicit trust and requiring access decisions at the resource level.

FAQ