An npm worm, previously dormant for over three months, has resurfaced, carrying a malicious file connected to a past supply-chain attack. This reemergence highlights how known threats can infiltrate developer environments through regular software packages.
Recent Activity Details
On September 7, four packages were uploaded within one hour, marking the worm’s return. Once a developer installs an infected dependency, the malware activates before any normal operations, searches for access tokens, and exploits the victim’s publishing rights to propagate further. This risk mirrors other npm supply-chain attacks, where a seemingly trusted update becomes the entry point.
Analysts from Aikido identified the payload, noting its identical SHA-256 value to the file used in a May 19 attack on @antv packages. Aikido reported a 111-day lapse between the last known incident and its current reappearance. The previous attack was significant, with a compromised account releasing 639 malicious versions of @antv packages within an hour.
Analysis of the Resurfacing
The worm’s latest activity involved four packages published by the same npm account, relying on an unchanged payload that had been publicly known for months. This approach offers attackers a straightforward path into trusted development workflows, posing a challenge for malware scanning techniques.
The payload executes during installation, validating stolen tokens against the npm registry, downloading package archives, injecting code, increasing version numbers, and republishing altered releases. This cycle illustrates how a single compromised developer account can escalate into a broader supply-chain issue.
Security Measures for Developers
In July, npm introduced a publish-time scanning system, delaying package availability by five to 15 minutes to detect malware. However, the worm’s reactivation suggests that registry checks may not always identify previously cataloged threats.
Developers should inspect whether the four flagged versions were installed on workstations, continuous integration jobs, or build caches. It’s crucial to rotate npm, GitHub, and cloud credentials potentially exposed, and review recent package releases from affected accounts.
Organizations should pin approved dependency versions, scrutinize installation scripts and package archives, and restrict publishing tokens’ scope and lifespan. Although blocking installation scripts reduces risk, it’s not foolproof, particularly when malicious code uses alternative methods.
Conclusion and Future Outlook
The main concern is not that every scanner misses every threat, but rather that a known payload with a public hash and detection history has re-entered a major package ecosystem unchanged. Developers and registry operators must verify layered controls, monitor publishing activities, and remain vigilant for dormant malware reactivating without warning.
Indicators of Compromise (IoCs):
- Malicious npm packages: [email protected], [email protected], [email protected], [email protected]
- Domain: t[.]m-kosche[.]com
- SHA-256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6
- File: index.js
- Execution command: bun run index.js
- Persistence files: .vscode/tasks.json, .claude/settings.json
Stay informed about active malware threats and phishing attempts to enhance your cybersecurity defenses. Consider using platforms like ANYRUN for early detection to mitigate incidents promptly.
