Known npm Worm Returns After 111 Days and Security Scanning Still Let It Through

A known Shai-Hulud npm worm payload has resurfaced after 111 days of inactivity, raising fresh questions about the effectiveness of registry-level malware screening.

The May campaign demonstrated how quickly a single compromised maintainer account can turn into a software supply-chain incident.

Attackers pushed malicious versions across npm packages, including widely used visualization and frontend dependencies.

The malware executed during installation, harvested credentials from developer workstations and CI/CD runners, and used stolen npm publishing tokens to spread to additional packages.

The newly observed activity is notable not because it introduces a novel evasion method, but because it apparently does not.

Researchers identified the returned payload by the SHA-256 hash e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 the same artifact previously associated with the @antv wave.

Detection history reportedly shows 319 package versions carrying that hash on May 19, followed by no additional sightings until September 7, a 111-day dormancy interval.

The worm was reportedly republished through four packages uploaded within the same hour from the same npm account:

feishu-docx-mcp@0.3.2, bmc-i18n-extract-cli@1.1.1, blueai-cli@0.7.0, and bmc-translate-utils@1.1.1.

That limited package count should not minimize the incident. A known malicious binary returning unchanged after more than three months represents a basic test of registry scanning, threat-intelligence ingestion, and package reputation controls.

The issue is especially concerning because npm introduced publish-time malware scanning designed to hold new publications briefly for automated analysis before they become installable.

Aikido Researchers said that, the reactivated packages reportedly carried a byte-for-byte identical payload already linked to the May 19 compromise of hundreds of packages in the @antv ecosystem.

npm Worm Returns After 111 Days

An exact SHA-256 match is among the simplest detection opportunities in malware defense.

It does not require executing suspicious code, defeating obfuscation, resolving multi-stage delivery logic, or analyzing a payload’s behavior in a sandbox.

It requires comparison against a known-malicious fingerprint. In this case, the hash had already been publicly analyzed and associated with an extensive supply-chain campaign.

The earlier Mini Shai-Hulud activity used malicious lifecycle hooks such as preinstall to execute code during npm install.

In affected @antv packages, the injected loader used bun run index.js, while some releases included an optional GitHub dependency that created another execution path outside the normal npm package payload.

Once executed, the malware searched for GitHub and npm tokens, cloud credentials, SSH keys, Docker authentication files, Kubernetes service-account tokens, Vault secrets, environment variables, and database connection strings.

It also targeted CI/CD infrastructure and, where it obtained valid GitHub tokens, created attacker-controlled repositories to store exfiltrated data.

The worm component makes the campaign materially more dangerous than a conventional credential stealer.

Stolen npm credentials can enable an attacker to enumerate packages a maintainer is authorized to publish, inject the malicious code into package archives, increment versions, and republish them.

Each exposed maintainer account can therefore become a propagation point into other projects.

Publish-time scanning remains valuable, but this event highlights its limits.

Malware that is novel, encrypted, heavily staged, or activated only under narrowly defined runtime conditions is difficult to classify reliably before publication.

However, an unchanged file matching a publicly documented malicious hash should be a baseline block condition.

The deeper concern is that hash-only scanning is insufficient even when it works.

An attacker who changes a single byte, repacks an archive, alters obfuscation, or moves the payload into a remote dependency can generate a new fingerprint while retaining the same malicious functionality.

Shai-Hulud’s previous campaigns already demonstrated use of obfuscated JavaScript, lifecycle execution, and GitHub-hosted “exotic” dependencies to expand the attack surface.

Organizations should immediately review lockfiles, package caches, build logs, and software bills of materials for the four newly named package versions and for historical Shai-Hulud indicators.

Teams that installed affected releases should treat developer endpoints and CI runners as potentially exposed, rotate npm and GitHub tokens, review cloud and deployment credentials, and investigate unauthorized package publishing activity.

Security teams should also inspect package.json changes for unexpected lifecycle scripts, particularly preinstall, postinstall, and commands invoking Bun or unknown shell scripts.

The previous campaign also modified .vscode/tasks.json and .claude/settings.json, meaning package removal alone may not eliminate persistence from compromised systems.

The return of an unchanged Shai-Hulud payload is a reminder that supply-chain security cannot depend solely on post-publication detection or registry assurances.

Pinning dependencies with lockfiles, limiting maintainer token scope, enforcing short-lived credentials, restricting lifecycle scripts in CI, and delaying adoption of newly published versions can reduce the opportunity for a worm to execute before detection catches up.

IOCs

Network	Files	Persistence
t[.]m-kosche[.]com Command-and-control (C2) domain linked to the original May campaign wave.	SHA-256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 Root-level index.js payload. preinstall script executes bun run index.js.	.vscode/tasks.json can configure Visual Studio Code tasks that execute attacker-controlled commands. .claude/settings.json can modify Claude Code/project settings to support execution.

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.