- The Shai-Hulud worm, previously linked to a massive @antv package attack in May, has reappeared on npm after a 111-day gap, slipping through newly introduced publish-time malware scanning.
- Security researchers at Aikido Security detected four malicious packages uploaded within an hour, all carrying the exact same payload hash as the original worm, raising concerns about the effectiveness of npm's automated defenses.
- The reactivated worm used identical infection mechanisms, including the same command-and-control domain and persistence files, yet managed to evade detection, highlighting a significant gap between claimed scanning capabilities and actual protection.
Four months after the security community believed the Shai-Hulud worm had been neutralized, it has unexpectedly resurfaced in the npm ecosystem. This malicious strain, which first gained notoriety in May when a compromised maintainer account pushed 639 tainted versions of @antv packages within a single hour, has now reappeared in a smaller but equally concerning wave. Researchers at Aikido Security observed four packages uploaded during a narrow one-hour window following an extended silence of 111 days, and the payloads were anything but new.
What makes this resurgence particularly alarming is that the new packages contained the exact same hash as the original May wave, meaning the threat actor reused the malicious code without any modification. According to Charlie Eriksen, a security analyst at Aikido, the worm slipped through npm’s newly implemented publish-time malware scanning system—a process that holds each package for five to fifteen minutes for automated analysis before making it available to developers. This automated screening is supposed to catch known threats, especially those with publicly documented signatures and extensive vendor write-ups.
The Slippery Gap in Registry-Level Scanning
The rediscovery of Shai-Hulud points to a critical flaw in how npm positions its security measures. While the registry now advertises that every new publication undergoes malware scanning, the fact that a hash-identical reactivation managed to bypass this layer raises serious questions. Eriksen emphasized that signature matching against known malicious artifacts is the most basic form of defense—it requires no behavioral analysis, sandboxing, or deep inspection of obfuscated code. Yet even this fundamental check was missed in the recent uploads.
“This payload wasn’t novel, repacked, or even lightly modified to dodge signature matching,” Eriksen noted. “It was the same 64 hex characters that had been on files since May.” The four packages in question were 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. All of them carried a preinstall script that executed bun run index.js, alongside persistent files in .vscode/tasks.json and claude/settings.json, mirroring the exact infection chain seen months earlier.
The command-and-control infrastructure also remained unchanged, with the same domain tm-koschecom associated with the original wave. Additionally, the malicious payload hash e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6 was identical to the one documented in May. This level of reuse should have been trivial for any automated scanner to flag, yet it slipped through, leading Eriksen to call the situation “the real story here.” He pointed out that while multi-stage loaders, dependency confusion, and supply chain attacks are genuinely hard problems, an exact hash match to a worm that made international security news four months ago is not.
Behavioral Indicators and What Teams Should Watch For
Aikido Security has released a set of indicators that organizations can use to detect potential infections related to this Shai-Hulud reactivation. Besides the known domain and hash, behavioral patterns include outbound validation calls against the npm registry using stolen tokens, tarball downloads, payload injection, version bumps, and a republish cycle. The worm also mass-creates GitHub repositories with Dune-themed naming and reversed “Shai-Hulud” strings in descriptions—a distinctive signature that security teams familiar with the original campaign can easily spot.
“A file hash match is a lookup, not a hard problem. It requires no behavioral analysis, sandboxing, or reasoning about obfuscated code’s intent,” Eriksen commented. His frustration reflects a broader concern: registry-level scanning promises to protect developers, but if it fails to catch such obvious reuse, its effectiveness is questionable. The 111-day gap also suggests that the threat actor waited deliberately, perhaps assuming the heat would die down, only to reactivate the same worm with minimal effort.
ITPro reached out to npm for official comment but did not receive a response by the time of publication. This silence only adds to the unease, as developers rely on npm to be a trusted source of open-source packages. The incident underscores that publish-time malware scanning is not a silver bullet; it requires continuous improvement and perhaps more aggressive signature matching, especially for known-threat indicators with months of coverage.
What This Means for the Developer Community
The reappearance of Shai-Hulud is a wake-up call for both npm maintainers and users. While the number of compromised packages in this latest wave is relatively small (four, compared to 639 in May), the fact that they bypassed standard checks highlights a systemic weakness. Developers who rely on automated scanning to protect their npm supply chain may be lulled into a false sense of security. The worm’s ability to persist and strike again using unchanged code suggests that attackers are aware of the gaps in current defense mechanisms.
In response, security teams are advised to manually review preinstall scripts and check for suspicious domains, hash matches, and the specific persistence files mentioned above. They should also monitor their GitHub accounts for unexpected repository creation and any outbound traffic to tm-koschecom. The npm registry, for its part, needs to reassess its scanning thresholds—perhaps implementing stricter rules for packages that match known malicious hashes, regardless of how long ago the original attack occurred.
Ultimately, this incident demonstrates that basic security measures are still being missed in real-world deployments. While it’s unreasonable to expect scanners to catch every novel attack, failing to catch an exact hash match to a globally publicized worm is indefensible. The Shai-Hulud’s return may not have caused widespread damage this time, but it serves as a stark reminder that the fight against supply-chain attacks is far from over. Maintaining vigilance, keeping threat intelligence updated, and not relying solely on automated tools are essential steps for every developer and organization.
