DEV Community

Cover image for New Threats in Open Source: Worms, AI-Driven Malware, and Trust Abuse
Luis Manuel Rodriguez Berzosa for Xygeni Security

Posted on • Originally published at xygeni.io

New Threats in Open Source: Worms, AI-Driven Malware, and Trust Abuse

TL;DR

The open source supply chain threat landscape has fundamentally shifted. Three converging trends are redefining risk:

Self-Propagating Worms Have Arrived

  • Shai-Hulud (Sept 2025): First npm worm attack — stole credentials via postinstall hooks, then autonomously republished itself across ~700 package versions using compromised maintainer tokens.
  • GlassWorm (Oct 2025): VS Code extension malware using invisible Unicode-encoded payloads and unkillable blockchain-based C2 (Solana). 35 K+ installations, full RAT capabilities targeting crypto wallets.
  • Shai-Hulud 2.0 (Nov 2025): Cross-registry jump from npm to Maven Central via automated mirroring tools, plus GitHub Discussions weaponized as C2 and a destructive wiper fallback.

AI Is Now the Operator, Not Just the Tool

A documented cyber-espionage campaign achieved autonomous execution using Claude as an orchestration engine — reconnaissance, exploitation, lateral movement, and exfiltration with minimal human oversight.

The barrier to sophisticated attacks has collapsed from “expert team” to “someone who understands prompting.”

Infrastructure Abuse at Scale

The IndonesianFoods campaign flooded npm with ~44 000 spam packages exploiting blockchain reward systems (TEA Protocol), persisting for nearly two years before cleanup.

Red-team scenarios are also abusing OSS infrastructure.

Bottom Line

Every compromised developer machine is now a potential worm propagation point.

Credential theft enables autonomous spread.

AI can orchestrate attacks at machine speed.

Traditional detection and takedown approaches are failing against immutable C2 and cross-registry propagation.

Defense must assume compromise and focus on containment velocity.


New Threats to the Open Source Ecosystem: Worms, AI-Cooked Malware, and Large-Scale Trust Abuse

The open-source ecosystem is facing a paradigm shift in supply-chain threats.

Traditional malicious packages did not propagate on their own, AI was not a factor for threat actors, and the spread of attacks was limited.

In recent months, we have witnessed the convergence of three threat categories that, while concerning individually, represent a fundamental shift in the risk landscape for software development when considered together:

  • Self-propagating worms in package ecosystems: Malicious packages that spread autonomously through credential theft and automated republishing. This turns every compromised developer machine into a new infection vector.
  • AI-powered malware generation and exploitation: Threat actors use large-language models to write payloads, discover vulnerabilities, and orchestrate attacks at machine speed.
  • Large-scale trust exploitation: Some actors systematically abuse rewards for open-source contributions, repository infrastructure, and developer tools — creating bursts with thousands of spam-package publications that affect registries.

The key techniques enabling sophisticated software supply-chain attacks are no longer theoretical — they’re active, documented, and increasingly accessible to less-skilled threat actors.

The barrier to conducting supply-chain attacks has collapsed: what once required teams of experts can now be executed by AI agents with minimal human oversight.

This post examines recent incidents directly involving malicious open-source packages or abusing AI and OSS infrastructure, analyzes the new techniques that enabled them, and explores emerging capabilities that may define the next generation of threats.

In the last section, we’ll examine what can be done to limit the risk.

NOTE: AI-generated poster, which shows fatal flaws in understanding what’s going on.

AI is far from perfect for certain usages.


Sha1-Hulud: Npm’s First Self-Replicating Worm Attack

Discovered on September 14, 2025, Shai-Hulud represents the first documented self-propagating worm attack in the npm ecosystem.

The name was chosen by threat actors who appear to be fans of science fiction!

The attack began with compromised developer credentials — likely obtained through phishing campaigns spoofing npm login prompts or MFA bypasses. Once inside, the worm executed a multi-stage attack that transformed credential theft into autonomous propagation.

The incident was severe enough to warrant a CISA Alert.

Technical Architecture

The malware operates through a Webpack-bundled, heavily minified JavaScript payload (bundle.js) that executes via a postinstall hook…

Credential Harvesting

Upon execution, the payload implements comprehensive secret discovery:

  • Dumps process.env and scans filesystem for high-entropy secrets.
  • Executes TruffleHog for systematic credential scanning.
  • Queries cloud metadata endpoints (169.254.169.254, metadata.google.internal).
  • Targets npm tokens in .npmrc, GitHub PATs, and CI/CD secrets.

Exfiltration Infrastructure

The worm employs multiple exfiltration strategies, including:

  • GitHub Actions abuse: workflows containing ${{ toJSON(secrets) }} that serialize all repository secrets.

Autonomous Propagation

The worm’s self-replication mechanism operates through the following algorithm (pseudo-code):

function propagate(token, owner) { 
    userPackages = npmApi.listPackages(owner, token);
    for (pkg in userPackages) {
        tgz = npmApi.fetchTarball(pkg, token);
        modified = injectBundleAndPostinstall(tgz);
        npmApi.publish(modified, token);
    }
Enter fullscreen mode Exit fullscreen mode

With any stolen npm token, the worm enumerates all packages owned by the compromised maintainer, injects bundle.js with a postinstall hook, and republishes.

This autonomous behavior caused infection counts to jump from dozens to hundreds of packages within hours.

Impact Metrics

  • Initial detection: September 14, 2025, by Daniel Pereira.

    “Patient zero” seems to be rxnt-authentication:0.0.3.

  • Attack blast radius: ~700 malicious package versions published, affecting high-profile projects with millions of weekly downloads.

    Limited to npm packages and GitHub repositories.

  • Infrastructure: C2 at 217.69.3.218, exfiltration to 140.82.52.31:80/wall.

  • Persistence: GitHub workflows on branches named shai-hulud.

  • Observable indicators: Repos flipped to public with -migration suffix.

Shai-Hulud is a secret-harvesting worm.

It did not attempt to steal money or wipe infrastructure.

The exfiltrated secrets and exposed repositories can be used for targeted attacks, so downstream damage may appear later.

The true cost lies in remediation, credential rotation, and the risk of secondary breaches.

One positive outcome was forcing GitHub/NPM to take immediate action:

deprecating legacy classic tokens and weak publishing credentials, moving toward the “OIDC Garden of Eden” of OpenSSF’s Trusted Publishing.

But keep reading — the worm emerged once again from the sands of Arrakis.


Sha1-Hulud 2.0: The Arrakis Worm Strikes Back

Two months after the initial Shai-Hulud campaign, threat actors returned with “The Second Coming”

a significantly more aggressive wave that learned from the weaknesses of the first attack.

The campaign self-identified through repositories labeled “Sha1-Hulud: The Second Coming.”

Let’s examine the key differences from the first wave.

The preinstall hook replaced the original postinstall execution vector.

According to Panther,

@asyncapi/avro-schema-parser@3.0.25 was “patient zero” for this second wave, exploiting a vulnerable pull_request_target workflow trigger.

(If you “know of a friend using that,” read Why Is pull_request_target So Dangerous?)

Cross-Registry Propagation

The worm spread from npm into Maven Central through automated mirroring.

The mvnpm tool — which converts npm packages into Maven artifacts with no security review —

automatically republished compromised npm packages such as posthog-node@4.18.1 as org.mvnpm:posthog-node:4.18.1.

This was the first known cross-registry worm, where an npm compromise impacted the Java ecosystem without direct interaction.

Maven Central removed the artifacts on November 25, 2025, but the exposure window still affected Java/JVM workloads and enterprise build systems.

Bun Runtime for Evasion

Attackers deployed a preinstall: node setup_bun.js hook that installed the Bun runtime to evade Node-specific monitoring.

Bun provided faster execution for the 480,000+ line obfuscated payload (bun_environment.js) and bypassed traditional Node.js instrumentation.

GitHub Actions as Command Infrastructure

The worm deployed hidden self-hosted GitHub Actions runners in $HOME/.dev-env/ across Windows, macOS, and Linux.

Even more advanced, it created discussion.yaml workflows that listened to GitHub Discussions events and executed discussion message bodies as shell commands —

effectively turning GitHub Discussions into an invisible C2 channel.

Destructive Wiper Capability

Unlike the first wave, which focused on credential harvesting, Shai-Hulud 2.0 introduced a destructive wiper triggered when no valid credentials were available for propagation.

This “dead-man switch” ensured damage even if replication failed, marking a shift from purely espionage-focused operations to potentially destructive campaigns.

Despite using stealth techniques (Bun runtime, obfuscation), the campaign was extremely noisy — republishing hundreds of packages, creating public repositories, uploading credential dumps, and installing long-lived self-hosted runners.

This aggressive tempo contrasts sharply with traditional supply-chain attacks that rely on stealth, suggesting either confidence in rapid impact or a deliberate overwhelm tactic to maximize short-term damage.


GlassWorm: Invisible Code Meets Blockchain C2

On October 17, 2025, a VS Code extension named GlassWorm introduced two unprecedented techniques to the supply-chain threat landscape:

invisible malicious code using Unicode stealth, and blockchain-based command and control infrastructure.

Unicode Stealth Technique

GlassWorm’s primary innovation lies in its abuse of Unicode variation selectors — special characters that produce no visual output but remain executable in JavaScript.

This allows malware to appear as blank lines in editors, GitHub diffs, and IDE syntax highlighting — breaking human code review by hiding executable logic in visually empty regions.

The attack targeted VS Code extensions in the OpenVSX marketplace.

Analysis of the CodeJoy extension (v1.8.3) revealed large invisible sections containing executable JavaScript encoded with unprintable Unicode characters.

To a developer reviewing the file, the content appeared normal — just empty lines.

To the JavaScript runtime, it was a complete malware payload.

Blockchain-Based C2 Architecture

GlassWorm implements an unkillable C2 mechanism using the Solana blockchain.

The malware scans for transactions from a hardcoded wallet address, where transaction memo fields contain JSON objects with base64-encoded URLs.

This architecture provides powerful advantages:

  • Immutability: Blockchain transactions cannot be modified or deleted.
  • Anonymity: Crypto wallets are pseudonymous and difficult to trace.
  • Censorship resistance: No hosting provider to pressure, no infrastructure to seize.
  • Legitimate traffic: Solana RPC traffic looks identical to normal blockchain activity.
  • Dynamic updates: New payload URLs can be pushed for less than $0.01 per transaction.

Even if defenders block the decoded payload server (217.69.3.218), attackers can simply publish a new transaction pointing to a different URL.

Every infected system automatically fetches the updated location.

Backup C2: Google Calendar

For redundancy, GlassWorm uses a Google Calendar event as a secondary C2 channel.

The event title contains a base64-encoded payload URL, which the malware decodes to fetch additional commands.

https://calendar.app.google/M2ZCvM8ULL56PD1d6
Event title: aHR0cDovLzIxNy42OS4zLjIxOC9nZXRfem9tYmlfcGF5bG9hZC9xUUQlMkZKb2kzV0NXU2s4Z2dHSGlUdg==
Decodes to: http://217.69.3.218/get_zombi_payload/qQD%2FJoi3WCWSk8ggGHiTdg%3D%3D
Enter fullscreen mode Exit fullscreen mode

This provides a legitimate service that bypasses security controls and can be updated simply by editing the calendar event.

Payload Delivery

The C2 servers deliver encrypted payloads using AES-256-CBC.

Decryption keys are generated per request and transmitted via custom HTTP headers, ensuring that intercepted payloads cannot be decrypted without a fresh request.

ZOMBI: Full-Spectrum RAT Capabilities

The final payload (ZOMBI) transforms infected developer workstations into criminal infrastructure:

  • SOCKS Proxy Server: Routes attacker traffic through victim networks, enabling internal access and anonymization.
  • WebRTC P2P: Establishes peer-to-peer control channels that bypass firewalls through NAT traversal.
  • BitTorrent DHT: Uses distributed hash tables for decentralized command distribution that cannot be shut down.
  • Hidden VNC (HVNC): Provides invisible remote desktop access running in virtual desktops that do not appear on screen or in Task Manager.

Cryptocurrency Wallet Targeting

ZOMBI actively hunts for 49 different cryptocurrency wallet extensions, including MetaMask, Phantom, and Coinbase Wallet.

Combined with invisible remote access, this enables direct theft of funds from developer machines.

Credential Harvesting and Propagation

Like Shai-Hulud, GlassWorm harvests npm tokens, GitHub credentials, and OpenVSX access tokens.

These credentials enable autonomous spread to additional packages and extensions, creating worm-like propagation behavior.

Impact Metrics

  • Initial detection: October 17, 2025
  • Total installations: 35,800+ across OpenVSX and VS Code marketplace (possibly bot-inflated)
  • Compromised extensions: 16 confirmed (15 OpenVSX, 1 Microsoft marketplace)
  • Infrastructure: Primary C2 at 217.69.3.218, exfiltration to 140.82.52.31:80/wall
  • Blockchain wallet: 28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2 (Solana)
  • Current status: Active, with infrastructure operational as of this writing

AI-Orchestrated Cyber Espionage

We are all learning how to work with AI tools.

Looking at the techniques used by recent attacks, one may wonder: are threat actors using AI to create malware?

Certainly. But they can scale attacks even further by weaponizing AI for orchestration.

What follows is a cyber-espionage campaign — but imagine these same techniques applied to automated OSS-targeted attacks.

In September 2025, Anthropic detected and disrupted the first documented cyberattack executed largely without human intervention.

The campaign achieved 80–90% autonomous execution using Claude Code as an orchestration engine, with AI agents performing reconnaissance, exploitation, lateral movement, and data exfiltration.

This marks the shift from AI-assisted attacks to AI-orchestrated cyber operations.

The threat actor, GTG-1002 (a Chinese state-sponsored group), targeted ~30 organizations across technology, finance, and government sectors.

They developed an autonomous framework turning Claude Code from a coding assistant into a cyber-operations engine.

AI as Orchestration System

Rather than using AI as an advisor, GTG-1002 used Claude as the primary operator.

The framework broke multi-stage attacks into isolated tasks, each appearing benign on its own.

Through carefully crafted prompts and established personas, attackers induced Claude to execute harmful actions without realizing their malicious context.

AI carried out technical steps while the orchestration engine tracked campaign state, managed phase transitions, and aggregated results across days-long sessions.

Human involvement was limited to high-level supervision: initialization, target selection, approving escalations, and validating exfiltration.

Commodity tools — network scanners, database exploits — were orchestrated through custom MCP servers.

This approach automates operations at speeds impossible for humans.

Claude even analyzed stolen data to prioritize valuable information, maintaining persistent context across sessions while human operators returned later to review progress.

Social Engineering the AI: Bypassing Safety Controls

The campaign’s success relied on convincing Claude to perform cyber-intrusion tasks despite its safety training.

The technique: role-play deception.

Attackers posed as cybersecurity analysts performing legitimate investigations.

Combined with task isolation, this was enough to jailbreak AI safety controls.

Hallucinations Are Great!

Claude frequently hallucinated results — reporting successful exploits that failed, inventing credentials, fabricating discoveries.

For now, this limits fully autonomous operations, but as models improve, these weaknesses will diminish.

Until then, a common AI flaw is, ironically, our best friend 🙃.

Detection and Response

Anthropic detected the campaign through anomalous usage patterns indicating systematic intrusion behavior.

They banned associated accounts, notified affected organizations, coordinated with authorities, and integrated attack patterns into broader safety controls.

Supply Chain Implications

Every technique demonstrated here transfers directly to package ecosystems.

AI could autonomously discover vulnerable maintainers, generate malicious packages, and orchestrate registry-wide attacks at machine speed.

The barrier has dropped from “team of expert cybercriminals” to “operator who understands AI prompting.”

Need a real-world example of AI conscription for cyberattacks?

Read ShadowRay 2.0: Attackers Turn AI Against Itself in a Global Campaign,

where adversaries used Ray’s orchestration features (“the Kubernetes of AI”) to run a global cryptojacking botnet that spread autonomously across exposed Ray clusters.

Another example:

S1ngularity attack, exploiting the same pull_request_target issue mentioned earlier.

It detects locally installed AI CLI tools (Claude, Gemini, Q with bypass flags) and uses them for reconnaissance.

From telemetry.js payloads, prompts included things like this.

Infrastructure Abuse: Large-Scale Package Spam Campaigns

In addition to malware-distributing packages, the open-source ecosystem faces infrastructure abuse through spam campaigns that flood registries with thousands of packages.

DevOps for cybercrime is common: attackers routinely use SCMs and registries for OSINT, distributing malware stages, extracting secrets, and maintaining C2.

But these platforms can also be abused for non-malicious purposes.

While not traditionally malicious, such campaigns consume registry resources, pollute search results, and erode trust.

Two significant examples demonstrate this trend: IndonesianFoods (exploiting contributor rewards) and the Elves campaign (red-team testing gone rogue).

IndonesianFoods: TEA Protocol Exploitation

The primary motivation was financial fraud through exploitation of the TEA Protocol

a blockchain-based system designed to compensate open-source developers.

Attackers published thousands of interconnected packages containing tea.yaml files linking to their Ethereum wallets, forming circular dependency networks to inflate contribution metrics.

Automated scripts published ~12 packages per minute with randomly generated Indonesian names and food terms.

One package README even boasted about TEA token earnings, confirming the financial motive.

The campaign spanned ~44,000 packages — over 1% of npm — and persisted nearly two years.

Circular dependencies meant installing one package could pull in hundreds of spam packages.

Search results degraded, trust in package metrics eroded, and registry bandwidth and storage were heavily consumed.

Although TEA protocol abuse was documented in April 2024, systematic removal didn’t occur until November 2025, revealing critical gaps in registry abuse detection.

The episode undermined confidence in blockchain-backed funding models and exposed how easily reward systems can be gamed.

Elves Campaign: Automated Infrastructure Testing

The elves campaign in December 2025 emphasized infrastructure abuse rather than malicious intent.

Package descriptions referenced “capture the flag challenge” and “testing” (including French text:

“Package généré automatiquement toutes les 2 minutes”), suggesting origins in security research or CTF exercises.

Packages followed consistent elf-stats-* naming with seasonal themes.

Some contained trivial reverse shells (simple bash one-liners), so unsophisticated they appeared designed only for detection testing rather than genuine exploitation.

The operational tempo — one package every 2 minutes across multiple accounts — tested npm’s rate limiting and abuse detection capabilities.

The campaign demonstrated that automated flooding can persist for hours or days before intervention, consuming storage, bandwidth, and moderation resources.

Most importantly, it signaled to other threat actors that automated flooding attacks are feasible, potentially inspiring future abuse campaigns.

New Tactics, Techniques, and Procedures (TTPs)

TTP Technique Impact Detection
Autonomous Propagation Through Credential Reuse After harvesting npm tokens, GitHub credentials, or registry API keys, malware enumerates all packages owned by the compromised maintainer and injects malicious payloads into new versions. One compromised token can infect dozens or hundreds of packages within hours. Each new victim becomes a propagation point for additional spread. Monitor for sudden bursts of package publications from single maintainers, especially with suspicious postinstall hooks or large binary additions.
Multi-Layer C2 Infrastructure with Blockchain Immutability Primary C2 uses blockchain transactions (Solana, Ethereum) with memo fields containing encoded payload URLs. Secondary C2 leverages Google Calendar, Pastebin, or GitHub Gists as backup channels. Traditional takedown approaches fail—blockchain transactions cannot be removed, and legitimate service abuse is difficult to distinguish from normal use. Monitor for unusual blockchain RPC queries from developer machines. Track calendar or paste-site connections from build environments.
Invisible Code Injection via Unicode Stealth Malicious JavaScript encoded with Unicode variation selectors and zero-width characters that don’t render in editors but remain executable. Code review becomes ineffective; developers see blank lines while interpreters execute hidden malware. Scan for unprintable Unicode characters, especially variation selectors or zero-width joiners. Analyze byte-level content, not rendered code.
GitHub Actions as Exfiltration Infrastructure Workflows with ${{ toJSON(secrets) }} serialize all repository secrets and POST them to attacker-controlled endpoints. Complete secret theft disguised as CI/CD activity, with traffic from GitHub’s trusted IP ranges. Scan workflows for toJSON(secrets). Monitor external HTTP POST requests and new workflow additions without PRs or commit history.
Hybrid RAT Deployment in Dev Environments Full RAT capabilities (SOCKS proxy, VNC, WebRTC P2P) on developer workstations. Targets development credentials and internal networks. Developers become pivots for source code, pipelines, and cloud infrastructure access. Detect unexpected proxy or VNC processes, WebRTC connections, and BitTorrent DHT activity from dev machines. Enforce strict egress filtering.
Dependency Chain Infection Malicious packages depend on other attacker-controlled packages, forming recursive chains. Installing one malicious dependency can introduce dozens more; cleanup is complex. Analyze dependency graphs for circular or random patterns. Enforce lockfile-only installs to prevent uncontrolled dependency resolution.

Defensive Posture

The era of self-propagating supply chain worms has arrived.

Defense requires automation, vigilance, and architectural controls that assume compromise rather than hoping for detection.

Every package installation is a potential infection vector.

Every credential is a propagation mechanism.

The question is no longer whether attacks will occur, but how quickly you can detect and contain them.

Defending against worm-like malicious packages requires shifting from reactive scanning to proactive prevention and continuous monitoring.

Pipeline Controls

  • Enforce lockfile-only installs (npm ci, yarn install --frozen-lockfile) to prevent automatic dependency updates and ensure strict version pinning.
  • Implement pre-install scanning of packages and full dependency trees, blocking malicious packages before execution.
  • Block packages with suspicious traits: oversized bundles, obfuscation, or unexpected install hooks.
  • Require code review for dependency additions and updates.

Credential Management

  • Minimize token scope — publishing tokens should target only specific packages.
  • Use short-lived tokens with automatic rotation.
  • Never store tokens in source code or environment variables.
  • Use dedicated CI accounts with minimal privileges.

Detection and Monitoring

  • Track publishing patterns and alert on unusual bursts from single maintainers.
  • Monitor GitHub Actions for secret serialization patterns (toJSON(secrets)).
  • Detect workflow additions performing external HTTP requests.
  • Flag new public repositories with encoded or suspicious content.
  • Watch for unexpected proxy, VNC, or blockchain RPC activity from developer machines.

Incident Response

  • Treat any execution of suspicious install hooks as full compromise.
  • Assume all tokens on compromised hosts are stolen — rotate immediately.
  • Rebuild affected CI/CD runners from clean images.
  • Audit all packages owned by compromised accounts for malicious versions.
  • Check for persistence in GitHub workflows and repository settings.

AI vendors often say any tool can be used for good or evil.

AI systems cannot entirely prevent dual use, but they can impose friction and improve forensic visibility.

The real design question is not “can AI be abused?” but “how much friction can we add without harming legitimate utility?”

One fact remains: jailbreaking today’s AI systems is far too easy.

Analysis of malicious prompts in recent attacks shows that LLM non-determinism extends to their guardrails.

Emerging ideas for AI security include strong origin authentication, trustworthy content isolation, and policy-aware external controls (with MCP and similar protocols now entering the landscape).

Only time will tell whether AI becomes the next weapon for large-scale OSS attacks.


Read More


About the Author

Written by Luis Rodríguez,

Co-Founder and CTO at Xygeni Security.

Luis is a physicist, mathematician, and CISSP with over 20 years of experience in software security.

He has led major security initiatives across SAST, SCA, and advanced code-analysis technologies.

Today, he focuses on software supply chain security, combining deep research with hands-on engineering to help teams defend modern DevSecOps pipelines from emerging threats.

Top comments (1)

Collapse
 
devrel_xygeni profile image
Fátima Said Xygeni Security

Great Article @lmrb1968 !