ZeroHour
The Hacker Newspublished ()ingested @TheHackersNews

Researchers Build Self-Replicating AI Worm That Operates Entirely on Local, Open

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2026-31431
Local Privilege Escalation (Copy Fail) in Linux Kernel algif_aead Interface

CVE-2026-31431 ('Copy Fail') is an incorrect resource transfer between spheres (CWE-669/CWE-1288) in the Linux kernel's algif_aead implementation of the AF_ALG userspace crypto interface, introduced roughly nine years ago (around 2017, per public reporting) when commit 72548b093ee3 switched AEAD operations to in-place handling even though the source and destination buffers come from different mappings. A local, unprivileged user can trigger the flaw by performing AEAD operations through the AF_ALG socket interface, causing the kernel to mishandle the copy of ciphertext and associated data. Successful exploitation provides a reliable local privilege escalation to root (C:H/I:H/A:H per the CVSS vector). Nearly every major Linux distribution and enterprise platform is exposed, including the kernel itself, Red Hat Enterprise Linux (including AUS, EUS, TUS and Update Services for SAP Solutions), OpenShift Container Platform, Amazon Linux, Ubuntu, Debian, openSUSE Leap, SUSE CaaS Platform, NixOS, and Linux-based products from Arista and Siemens. The flaw has public proof-of-concept code, a 99.9% EPSS score, and was added to CISA's Known Exploited Vulnerabilities catalog on 2026-05-01, indicating exploitation in the wild (ransomware use is unknown).

Do: Patch by installing the kernel update for CVE-2026-31431 through your distribution's security channel (Red Hat Enterprise Linux including AUS/EUS/TUS/SAP channels, OpenShift, Amazon Linux, Ubuntu, Debian, openSUSE Leap, SUSE CaaS Platform, NixOS, and Arista/Siemens firmware/software as applicable) and reboot into the patched kernel; the data provides no fixed version numbers, so defer to vendor advisories. Because the flaw is in CISA's KEV catalog (added 2026-05-01) with a 99.9% EPSS score, prioritize internet-reachable and multi-user systems first and follow BOD 22-01 guidance for cloud services. Check running kernel versions ('uname -r') and distribution advisory status to confirm you are on a fixed build.

7.8100% KEV PoC ×5
  • Linux kernel (algif_aead / AF_ALG crypto interface)
  • Red Hat Enterprise Linux (including AUS, EUS, TUS, and Update Services for SAP Solutions)
  • Red Hat OpenShift Container Platform
  • +8 more
masshundreds of millions to billions of installations (servers, cloud instances, desktops, and Android/embedded devices running affected kernel generations)
CVE-2026-39987
Unauthenticated Remote Code Execution in Marimo Python Notebook

Marimo, a reactive Python notebook, contains an unauthenticated remote code execution flaw (CVE-2026-39987, CWE-306; CVSS 4.0: 9.3 Critical) because its terminal WebSocket endpoint /terminal/ws skips authentication entirely. Unlike other WebSocket endpoints such as /ws, which call validate_auth(), /terminal/ws only checks the running mode and platform support before accepting connections, so any unauthenticated attacker who can reach the server can obtain a full PTY shell and execute arbitrary system commands on the host. All marimo deployments running versions prior to 0.23.0 are affected, with internet-exposed instances at greatest risk. Exploitation is confirmed in the wild: the flaw was added to CISA's KEV catalog on 2026-04-23, public PoCs exist, and reporting shows it was exploited within roughly 10 hours of disclosure, with observed post-exploitation activity involving LLM agents. EPSS assigns a 98.9% probability of exploitation within 30 days (100th percentile).

Do: Upgrade marimo to 0.23.0 or later; until patched, restrict access to the /terminal/ws WebSocket endpoint by binding the notebook to localhost, a VPN, or an authenticating reverse proxy. Identify whether any marimo instances are internet-exposed and review logs for connections to /terminal/ws and unexpected shell or process spawns, given reports of LLM-agent-driven post-exploitation on compromised instances. As a KEV entry (added 2026-04-23), this requires federal agencies to apply the vendor fix or mitigations per BOD 22-01 timelines.

9.399% KEV PoC ×4
  • Marimo (reactive Python notebook) all versions prior to 0.23.0
  • CoreWeave marimo all versions prior to 0.23.0
moderatelikely tens of thousands of users, with directly internet-exposed marimo servers plausibly in the low thousands
CVE-2026-43284
Linux kernel ESP-in-UDP decrypts in place over shared splice pages (CWE-123)

CVE-2026-43284 is a write-what-where memory-safety flaw (CWE-123) in the Linux kernel's xfrm/ESP (IPsec) code: the IPv4/IPv6 UDP datagram send paths fail to mark pages spliced into a UDP skb with SKBFL_SHARED_FRAG when MSG_SPLICE_PAGES attaches pipe pages, so the ESP input path wrongly treats the packet as privately owned and decrypts it in place over memory the skb does not exclusively own. It is triggered when locally generated UDP traffic built from spliced pipe pages is processed by the ESP decryption path, typically in IPsec NAT-traversal (ESP-in-UDP, UDP port 4500) configurations; the in-place decrypt can corrupt or expose data still referenced by the pipe or other owners of those shared pages. A local, low-privileged attacker can thereby cause high-severity confidentiality, integrity, and availability impact that extends beyond the packet itself (CVSS 3.1: 8.8, scope changed); no remote or unauthenticated trigger is described. Any Linux system running a kernel with the vulnerable UDP splice and ESP-in-UDP paths is affected, most importantly IPsec VPN gateways and clients; the advisory lists no affected version ranges. No public proof-of-concept or confirmed in-the-wild exploitation is known (not on CISA KEV), but EPSS assigns a 93.2% probability of exploitation within 30 days (100th percentile), so patching should not be deferred.

Do: Apply your distribution's kernel security update containing the xfrm/esp fix for CVE-2026-43284 and reboot into the patched kernel, prioritizing IPsec VPN gateways and clients that use ESP-in-UDP NAT-T (UDP/4500). Until patched, restrict untrusted local users from sending splice-based (MSG_SPLICE_PAGES) UDP traffic through IPsec-protected paths, or temporarily avoid ESP-in-UDP encapsulation where feasible. Verify the fix via your vendor's package changelog, as the advisory does not name specific fixed version numbers.

8.893%
  • Linux kernel
mass≈1M+ Linux installations carry the vulnerable code in default distro kernels; hundreds of thousands of hosts expose IPsec NAT-T (UDP/4500) in public internet…
CVE-2026-43500
Out-of-bounds write in Linux kernel AF_RXRPC decryption enables root access

CVE-2026-43500 is a memory-corruption flaw in the Linux kernel's AF_RXRPC (rxrpc) subsystem: the DATA and RESPONSE packet handlers only copy received skbs to a linear buffer before decryption when the skb is marked cloned, so non-cloned skbs that still carry externally owned paged fragments (SKBFL_SHARED_FRAG, e.g. set by splice() into a UDP socket, or skbs with a frag_list) fall through to the in-place decryption path. In that path the shared fragment pages are bound directly into the AEAD/skcipher scatter-gather list via skb_to_sgvec(), so decryption writes into pages shared with other kernel or user contexts, causing out-of-bounds/write-what-where corruption (CWE-787/CWE-123), notably via the splice-into-UDP-socket loopback vector. A local low-privileged attacker who can get the machine to process such rxrpc packets can corrupt kernel memory and escalate to root (CVSS 3.1: 7.8 high, local vector, high confidentiality/integrity/availability impact). Affected systems are Linux kernels with the AF_RXRPC subsystem available — the transport used by the AFS/kAFS network filesystem — which mainstream distribution kernels ship as a module or built-in; no specific affected or fixed version ranges are provided in the data. It is not on CISA's KEV list and the CVE record lists no public PoC, but news reports describe a 'Dirty Frag' local privilege-escalation exploit giving root across major distributions and a released PoC, and EPSS puts the 30-day exploitation probability at about 93% (100th percentile).

Do: Apply the kernel update containing the rxrpc fix as soon as your distribution ships it — the fix extends the unshare gate to also unshare skbs with frag lists or shared fragments before in-place decryption; no fixed version numbers are given in the available data, so follow your distro's security advisory. Until patched, check whether rxrpc/AFS is in use (e.g. 'lsmod | grep rxrpc') and avoid or restrict local splice()-into-UDP/loopback AFS traffic on multi-user hosts.

7.893%
  • Linux kernel
mass≈1 billion+ Linux installations (mainstream distro kernels ship AF_RXRPC)
Full article1,442 words · extracted from thehackernews.com · click to collapse

University of Toronto researchers have built and tested a proof-of-concept AI-driven computer worm that uses a locally hosted open-weight large language model to reason its way through a network, generate tailored attack strategies for each target it encounters, and replicate itself, all without human intervention and without touching a commercial AI service.

The preprint, posted to arXiv on June 2 and currently under peer review, shows why single-CVE patching breaks down when malware can inspect exposed services, read fresh advisories, and generate a new attack path at runtime.

In 15 isolated runs on a deliberately vulnerable 33-host network, the worm identified an average of 31.3 vulnerabilities and gained elevated access on 23.1 hosts, roughly three-quarters of the hosts it actively targeted. It then replicated autonomously to 20.4 of those hosts, or 62% of the full network, over seven days, with no prior knowledge of the network topology and no human input.

Traditional worms ship with a fixed exploit payload chosen at build time. Patch those specific bugs, and the worm stops spreading.

This worm does something different: it uses an open-weight LLM running on a single GPU to generate attack logic at runtime, tailored to whatever it finds on the next target. No pre-encoded exploit chain. No dependency on OpenAI, Anthropic, or any other API that a platform could revoke or rate-limit.

What the worm actually did

Led by associate professor Nicolas Papernot, the CleverHans Lab team spans the University of Toronto, Vector Institute, University of Cambridge, and ServiceNow. They ran 15 independent experiments on an isolated 33-host network ("FakeCorp") spanning Ubuntu, Debian, Rocky Linux, Alpine, Windows Server 2008 R2, 2019, and 2022, and IoT devices.

Each host had at least one real-world vulnerability. Five of the 33 machines had GPUs. In the main propagation experiments, the worm used a shared GPU inference pool to simulate compute acquired from victim machines. The team separately tested full GPU-tier replication, in which the worm stages a local LLM instance on a compromised GPU host; that succeeded in 68.8% of attempts.

In the tiered design, infected GPU-capable hosts serve as distributed reasoning nodes that provide inference for lower-compute devices on the network that cannot run the model themselves.

Across the 15 runs, the worm gained elevated access on 23.1 hosts and successfully launched a replica on 88% of those. It reached up to seven generations of self-replication, with a mean of 5.1. The setup was intentionally vulnerable: the paper says the test measures autonomous reasoning across realistic individual flaws, not spread through a mostly hardened production network under active endpoint defense.

Exploits across a single run included a chained SambaCry and writable root cron privilege escalation, Dirty Pipe, PrintNightmare, Drupalgeddon 2, Exim RCE, blind SQL injection, JWT bypass, Redis escape, and more, not because they were pre-programmed, but because the agent reasoned its way to them from what it found on each host.

The paper's Figure 2 maps the full radial propagation tree across one run, showing six to seven generations of spread across Linux, Windows, and IoT hosts. Individual exploit attempts succeeded about 44% of the time. Most failures came from malformed payload syntax, not flawed logic. Web app exploits and Windows privilege escalation were harder than Linux local escalation and service exploits, a capability ceiling the paper treats as a current model limitation, not a structural defense.

The patching-window problem

The worm bypassed its own training cutoff by ingesting public advisory text at runtime, successfully exploiting test hosts configured with three vulnerabilities disclosed after the model was trained:

Against those three hosts, the worm reached root in 41 of 67 attempts.

CVE-2026-39987 was disclosed on April 8, 2026. Sysdig observed exploitation in honeypots 9 hours and 41 minutes after that, and separately documented a real-world intrusion where an attacker used an LLM agent for post-exploitation activity after compromising a public Marimo instance. Same old patch gap, now with an agent reading the advisory and trying it at scale.

The relevant parallel to WannaCry is the patch gap, not the blast radius. EternalBlue had been patched for months before WannaCry struck. The paper is making the same point under a different constraint: an adaptive worm can keep testing new paths while defenders are still validating fixes.

Zero marginal cost, no central kill switch

Two things make this harder to contain than a traditional worm.

  • First, the cost shifts from rented API access to whatever compute the worm can capture. Once a GPU-capable victim infrastructure exists, the attacker no longer pays per attempt.
  • Second, because everything runs on open-weight models with no vendor dependency, provider-side controls miss the core problem. Service refusals, rate limiting, account suspension: none of it applies. There is no API key to revoke. Containment has to happen at the network and host layer.

The researchers also observed the worm rewrite its own code on several occasions to bypass local security controls in the test environment, behavior they never coded for.

The current version was deliberately built without stealth features: no encryption, no polymorphic code, no persistence mechanisms, no covering of tracks. A malicious variant with persistence, encrypted payloads, process masquerading, and log cleanup would give defenders fewer of the easy signals this prototype leaves behind.

Where this fits

This is not the first AI-driven worm research. Morris II (Cohen et al., 2025) showed a self-replicating adversarial prompt spreading across AI email assistants through retrieval-augmented generation, propagation within the AI application layer, not across host infrastructure.

In March 2026, ClawWorm demonstrated self-replicating attacks across LLM agent ecosystems, hijacking persistent configurations and propagating to agent peers. The Toronto worm is different in kind: the LLM is not the thing being attacked. It is the attack engine being used to compromise ordinary network infrastructure.

Real-world operations are already testing the same boundary. Anthropic said in November 2025 that it disrupted a large AI-orchestrated espionage campaign attributed with high confidence to GTG-1002, a Chinese state-sponsored group. Claude Code handled 80-90% of the operation, including reconnaissance, exploit development, credential harvesting, lateral movement, and exfiltration, with humans stepping in at a few decision points.

Google's Threat Intelligence Group reported a related shift in May 2026: what it assessed with high confidence to be the first zero-day exploit developed with AI assistance, found in a criminal group's script ahead of a planned mass exploitation event, alongside malware families that generate their own commands at runtime rather than relying on hardcoded logic. The Toronto work is the lab version of that direction pushed into host-level worm propagation.

The direction is clear enough: less prompting, more delegation, and more of the intrusion handed to the model.

What should defenders do now?

The behavioral signals this prototype produces give defenders something concrete to hunt for, because the current version does not try to hide.

  • Segment GPU-capable machines aggressively. The worm's design routes LLM inference through any compromised GPU host it can reach. In a flat network, one compromised deep-learning server becomes a reasoning hub for every infected device on the same subnet. Segment GPU infrastructure and apply zero-trust controls to prevent lateral reach to and from those hosts.
  • Treat published advisories as near-term weaponization targets. For internet-facing CVEs, the exploitation window is already measured in hours for some vulnerabilities. Verify exploitability fast, patch internet-facing exposure first, and use compensating controls when deployment cannot happen before the next business cycle.
  • Rotate credentials exposed on any compromised or credibly suspected host. The worm demonstrated systematic credential reuse as a propagation path. Harvested credentials move laterally faster than most detection cycles.
  • Monitor for agent-specific behavioral signals. Non-standard port activity, automated SSH public key injection, and clusters of LLM inference appearing on unexpected endpoints are the observable artifacts this prototype leaves behind. They are the starting point for detection logic.

In the test runs, that combination produced root on fresh vulnerabilities in 41 of 67 attempts and replication to 62% of the network in seven days with no further human input. Once a GPU foothold exists inside a flat network, the cost of mapping and exploiting additional hosts drops to whatever compute the worm can capture, while public advisories become immediate playbooks.

The implementation is not publicly released. The University of Toronto is establishing a vetting process for qualified defensive researchers to request access.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Text extracted automatically; images, tables and formatting may be missing. Original: https://thehackernews.com/2026/06/researchers-build-self-replicating-ai.html