A familiar npm worm has returned after more than three months of silence, carrying the same malicious file linked to an earlier supply-chain incident.
The reappearance shows how a known threat can regain access to developer environments when it is republished inside ordinary software packages.
The latest activity involved four packages uploaded within one hour on September 7. When a developer installs a poisoned dependency, the malware can run before normal work begins, look for access tokens, and use the victim’s publishing rights to spread into additional packages.
This is the same risk seen in other npm supply-chain attack reports, where a trusted update becomes the initial doorway. Analysts at Aikido identified the returning payload in triage work and found its SHA-256 value was identical to the file observed during the May 19 attack on @antv packages.
Aikido said in a report shared with Cyber Security News (CSN) that the result was a 111-day gap between the last known sighting and its renewed appearance.
The earlier wave was substantial: a compromised maintainer account pushed 639 malicious @antv package versions in one hour.
Aikido’s records counted 319 package versions carrying this file hash, all first detected on May 19, before four new releases surfaced on September 7. The new incident is smaller, but it matters because the code had already been widely identified.
Shai-Hulud npm Worm Resurfaces
The four returning releases were published by the same npm account. Their key feature was not a redesigned implant or newly concealed component, but reuse of a payload whose fingerprint had been public for months, offering attackers a shortcut into trusted development workflows.
That distinction is important. Malware scanning faces difficult cases involving hidden stages, delayed activity, or code that changes by environment.
Here, analysts said the sample was not repacked or lightly altered. It was an exact file-hash match, making the incident a test of known-malware detection rather than a contest with a novel evasion method.
The payload uses an install-time action to begin execution. It can validate stolen tokens against the npm registry, download package archives, insert code, increase a version number, and republish the altered release.
This automated cycle explains why worm infections across npm can quickly turn one compromised developer account into a wider supply-chain problem.
Its activity also extends beyond installation. The source material describes attempts to create project configuration files that may leave an execution path when a repository is opened later.
It also notes mass creation of GitHub repositories using Dune-related names and reversed Shai-Hulud references, behavior that can help defenders hunt for related activity.
What Developers Should Check
npm introduced publish-time scanning in July, holding packages for roughly five to 15 minutes before they become available for installation.
The system is intended to stop detectable malware before it reaches users. This reactivation suggests a registry check may still fail when it should recognize a previously cataloged malicious artifact.
Teams should review whether the four identified versions were installed in developer workstations, continuous-integration jobs, or build caches.
They should rotate npm, GitHub, cloud, and other secrets that may have been exposed, then examine recent package publications from affected accounts. The response mirrors lessons from the Keyv package compromise, where valid release channels amplified a stolen-credential attack.
Organizations should pin approved dependency versions, inspect installation scripts and package archives before promotion, and limit the scope and lifetime of publishing tokens.
Blocking installation scripts lowers risk, but is not a complete safeguard when malicious code uses alternative build or project configuration paths. Recent binding.gyp supply-chain attack coverage illustrates how attackers can avoid the checks teams expect to protect them.
The concern is not that every scanner misses every threat. It is that a payload with a known public hash and long detection history re-entered a major package ecosystem unchanged.
Developers and registry operators should verify layered controls, monitor publishing activity, and assume that dormant malware can return without warning at any time through familiar-looking package updates.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| Malicious npm packages | [email protected], [email protected], [email protected], [email protected] |
Packages that republished the identified Shai-Hulud payload on September 7 |
| Domain | t[.]m-kosche[.]com |
Command-and-control domain associated with the original May wave |
| SHA-256 | e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 |
Hash of the reused malicious payload |
| File | index.js |
Root-level payload file |
| Execution command | bun run index.js |
Command executed by the preinstall script |
| Persistence file | .vscode/tasks.json |
Visual Studio Code task configuration created by the malware |
| Persistence file | .claude/settings.json |
Claude configuration file created by the malware |
| Behavioral indicator | Outbound npm registry validation calls using stolen tokens | Token-validation activity observed after execution |
| Behavioral indicator | Tarball download, payload injection, version bump, republish cycle | Self-propagation workflow used to infect further packages |
| Behavioral indicator | GitHub repositories with Dune-themed names and reversed “Shai-Hulud” descriptions | Repository-creation pattern linked to the campaign |
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.
Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.
The post Shai-Hulud npm Worm Resurfaces After 111 Days and Slips Past Malware Scanning appeared first on Cyber Security News.
