Shai-Hulud npm Worm Returns After 111 Days, Exploits Known Payload

Posted on

After more than three months without activity, the Shai-Hulud npm worm has resurfaced, republishing a known malicious payload that had been publicly identified back in May. This episode underscores how even old, catalogued threats can slip past current malware scanning and compromise developer systems.

What Happened

On September 7, four npm packages were published within a single hour, all from the same maintainer account, that carried a malicious file whose SHA-256 hash matched one from a previously documented supply-chain attack. That earlier attack, which took place on May 19, involved the @antv namespace and saw hundreds of package versions pushed out. In total, 319 versions with the same hash were identified in May; these new September releases reactivated that exact payload. The 111-day gap between May 19 and September 7 marks the worm’s dormant period.

How It Works

The worm’s mechanism remains unchanged: during install-time, it executes actions that validate compromised tokens against the npm registry, fetch package tarballs, mutate code, increment version numbers, and republish packages. Once deployed, it also attempts to place project configuration files that create future execution paths when repositories are opened. And just as before, the cyber actors behind Shai-Hulud set up additional GitHub repositories with names referencing “Dune” or reversed forms of “Shai-Hulud,” giving defenders fresh clues to identify related infrastructure.

Detection and Security Gaps

npm has had publish-time scanning since July, holding packages for five to fifteen minutes before making them available. Yet this incident shows that scanning systems still fail to catch previously known malware when the payload is reused without modification. Since the hash is public, the failure appears to be skip detection rather than evasion via obfuscation.

Recommended Defenses

Developers and organizations are advised to inspect whether any of the four newly republished versions were ever used in systems, CI pipelines, or build caches. Secrets—npm tokens, GitHub credentials, cloud keys—should be rotated if there’s a possibility they were exposed. Additionally, reviewing recent package activity from affected accounts is critical.

Best practices that may reduce this risk include pinning dependency versions, auditing installation scripts, limiting token privileges and lifespan, and monitoring publishing actions. Though disabling install-scripts helps, it doesn’t fully block threats that leverage project configuration paths or alternative execution vectors.

Indicators of Compromise

Here are key signs to watch for:

  • Package names like [email protected], [email protected], [email protected], and [email protected] were the four new versions involved.
  • Domain t[.]m-kosche[.]com is associated with the original May attack.
  • Payload file was index.js, activated by the preinstall command bun run index.js.
  • Persistence artifacts include project config files: .vscode/tasks.json and .claude/settings.json.
  • Behavioral red flags: use of stolen tokens for registry validation, tarball downloads, code injection, version bumps, and republishing. Also, repository names with Dune themes or reversed “Shai-Hulud.”

What makes this resurgence particularly alarming is not simply that the same payload came back, but that it evaded detection despite its fingerprints being publicly available for months. Previous npm incidents—like the Keyv compromise—show how trusted release channels offer powerful leverage for attackers. As teams evaluate their supply-chain defenses, they’ll need layered safeguards, ongoing oversight of publishing behaviors, and the assumption that silent threats can reawaken without warning.

Related Posts