The Shai-Hulud npm worm is back several months after everyone assumed it was dead.
Back in May, a compromised maintainer account pushed 639 malicious versions of @antv packages to npm in a single hour, although the attack was swiftly halted.
However, while npm has since introduced publish-time malware scanning, researchers at Aikido Security spotted a “wormy boy” slipped through a triage queue.
“It had the same hash as the @AntV wave. Same payload,” Aikido Security’s Charlie Eriksen noted in a recent blog post.
Eriksen said four packages were uploaded within the space of an hour after a 111-day gap - and bypassing npm's new publish-time malware scanning, which sees every package held for five to 15 minutes while an automated system checks it before it becomes installable.
This marks a concerning new development in terms of Shai-Hulud-related risks, according to Eriksen.
While the scanners shouldn't be expected to catch everything, a worm payload with a public hash, extensive vendor write-ups, and months of detection coverage should not be slipping through the net on a registry that now markets itself as scanning every publish.
"That gap between what registry-level scanning claims to do and what a hash-identical reactivation shows it actually caught is the real story here," he said.
"Signature matching against known-malicious artifacts is the single easiest bar to clear in this industry, and it's the bar we should all be most alarmed to see missed."
The four packages concerned were:
- feishu-docx-mcp@0.3.2
- bmc-i18n-extract-cli@1.1.1
- blueai-cli@0.7.0
- bmc-translate-utils@1.1.1all
Keep an eye out for Shai-Hulud
According to Aikido, teams should be looking out for these and the command-and-control domain associated with the original May wave, t[.]m-kosche[.]com.
Other indicators of compromise include the hash of the reused malicious payload, e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6, the index.js root-level payload file ,and the command executed by the preinstall script, bun run index.js, along with the persistence files .vscode/tasks.json and claude/settings.json.
Behavioral indicators include outbound validation calls against npm registry using stolen tokens, tarball download, payload injection, version bump, republish cycle, and the mass creation of GitHub repositories with Dune-themed naming and reversed "Shai-Hulud" strings in descriptions.
“A file hash match is a lookup, not a hard problem. It requires no behavioral analysis, sandboxing, or reasoning about obfuscated code’s intent,” Erikson commented.
“And this payload wasn't novel, repacked, or even lightly modified to dodge signature matching. It was the same 64 hex characters that had been on file since May."
While the likes of multi-stage loaders, dependency confusion, and runtime-triggered payloads are genuinely hard problems, he said an exact hash match to a worm that made international security news four months ago isn't.
"That's the floor of what publish-time scanning is supposed to catch, and it got missed," he said.
ITPro approached npm for comment, but did not receive a response by time of publication.
FOLLOW US ON SOCIAL MEDIA
Follow ITPro on Google News and add us as a preferred source to keep tabs on all our latest news, analysis, views, and reviews.
You can also follow ITPro on LinkedIn, X, Facebook, and BlueSky.
Is full digital sovereignty achievable?
What happens to consent when the keys are handed to machines?
