In November 2025, the JavaScript ecosystem was shaken again by a devastating supply-chain attack: Shai-Hulud 2.0 - a new, more aggressive wave of the worm previously known as Shai-Hulud. This time, dozens of high-profile npm packages - including ones from major players like Zapier, ENS Domains, Postman, and others - were trojanized, putting potentially thousands of developers and organizations at risk.

As of late November 2025, researchers estimate that hundreds to ~700 npm packages were compromised, and the attack has already produced tens of thousands of malicious GitHub repositories, with some reports flagging 25,000+ repos created by the worm.

How the Attack Works (Again)

Initial Compromise

Rather than targeting random dependencies or typosquatting, attackers gained full access to legitimate maintainer accounts - in some cases by stealing credentials - and published malicious new versions of trusted packages.

Trojanized Packages and Preinstall Hook

What makes Shai-Hulud 2.0 especially insidious is its use of the npm install lifecycle. Each compromised package comes with a preinstall hook in its package.json. That hook triggers a script (setup_bun.js) which silently installs a separate runtime (Bun) if not already present, then executes a heavily obfuscated payload (bun_environment.js). From that point, the malicious logic runs outside the usual Node.js security visibility.

Credential Harvesting and Exfiltration

Once activated - whether on a developer's workstation or a CI/CD runner - the malware searches for all sorts of high-value secrets:

• npm publish tokens (allowing the worm to republish packages)
• GitHub tokens / credentials
• Cloud service keys (AWS, GCP, Azure)
• Other environment variables or secrets present in the environment

It then exfiltrates the harvested credentials - often by uploading them to public GitHub repositories under attacker control (frequently named something like "Shai-Hulud"), or by using GitHub Actions workflows to siphon secrets when CI runs.

Worm-like Self-Propagation

Using stolen npm tokens, the malware automatically re-publishes poisoned versions of other packages maintained by the compromised user, effectively turning each victim into a new infection vector. This allows exponential spread - turning one compromised maintainer into many more forking points.

Because the attack works at the install/pre-install phase, it's able to infiltrate CI/CD pipelines, developer laptops, and build servers - wherever a vulnerable npm install or build runs.

Why This Matters: The Impact

• Supply-chain trust broken - developers rely on npm packages being safe; this attack shows even "trusted" packages can suddenly become dangerous.
• Wide blast radius - with dozens/hundreds of packages compromised, many that are transitively depended on by thousands of projects, a single installation can unknowingly pull in malicious code.
• Credential and infrastructure exposure - stolen tokens can grant attackers access to private repos, cloud infrastructure, CI/CD pipelines, sensitive data, and more.
• Persistent compromise - even if the npm package is removed, malicious workflows or public repos may persist, continuing to leak secrets or build further attacks.
• Hard to detect - by using an alternative runtime (Bun) and obfuscated payloads, the malware aims to evade traditional static analysis or security tooling that only watches for typical Node.js behavior.

What You Should Do Right Now

If you maintain a project - open source or enterprise - and use npm (or depend on packages from npm), you should:

1. Audit your dependencies immediately - check if your projects (or your CI/CD pipelines) refer to any of the compromised packages or versions.
2. Remove or update any compromised versions; pull fresh, clean versions where available. For projects like the ones from Postman that pulled their packages quickly, ensure no infected package remains.
3. Rotate all secrets and tokens - GitHub tokens, cloud credentials, npm publish tokens, and any environment credentials that might have been exposed.
4. Inspect all repositories and CI/CD workflows - look for unusual GitHub Actions workflows (shai-hulud-workflow.yml or other unfamiliar YAMLs), and remove unexpected branches or public repos created by the attacker.
5. Harden future practices - consider isolating publishing to dedicated CI/CD pipelines, avoid carrying long-lived tokens on developer machines, enforce stricter MFA / token policies, and treat dependencies with more scrutiny (especially those updated recently). Many security advisories recommend freezing automated dependency updates until the all-clear.

The Bigger Picture: Supply-Chain Risk Is Real and Growing

While individual vulnerabilities or code bugs are often caught and patched, supply-chain attacks like Shai-Hulud exploit the implicit trust we place in open-source libraries and ecosystem tooling. In large organizations - especially those with many dependencies, complex CI/CD pipelines, and multiple contributors - the attack surface is huge.

Shai-Hulud 2.0 shows that attackers don't need to compromise your own code to infiltrate - they just need one trusted, widely used package to slip through. Once you install it, you might as well have invited the attacker into your infrastructure.

Given this reality, defending against such threats calls for more than reactive patching. It requires systemic supply-chain hygiene: continuous auditing, minimizing secrets exposure, strict governance over dependency changes, and runtime monitoring for abnormal behaviors.

How Prismor Can Help Protect Your Enterprise

At Prismor, we understand that modern software supply chains are complex. Here's how we can help you mitigate risks like Shai-Hulud 2.0:

• Automated Supply-Chain Monitoring: Prismor continuously scans your dependencies (npm, internal packages, third-party libraries) to flag known malicious packages, risky updates, or suspicious lifecycle scripts - before they enter your build or deployment pipelines.
• Credential and Token Vaulting: Prismor helps centralize secrets management - so developer machines or CI runners aren't cluttered with long-lived tokens that can be harvested by malicious scripts.
• CI/CD Hardening and Policy Enforcement: By enforcing strict policies around who can publish packages, review changes, and approve updates, Prismor reduces the risk of compromised maintainer accounts propagating malware through your organization.
• Post-Incident Audit and Containment: In the event of a suspected breach, Prismor allows you to quickly trace where compromised packages touched your environment - which services, build agents, or repos - and trigger credential rotation or rollback.
• Continuous Threat Intelligence and Software-Bill-of-Materials (SBOM) Tracking: Prismor can integrate SBOMs into your development lifecycle to maintain visibility of exactly what code (and dependencies) make up your applications, giving you a "source of truth" for detecting any untrusted or unexpected additions.

By combining automation, policy enforcement, and visibility across your entire software supply-chain, Prismor helps make attacks like Shai-Hulud far harder to pull off - and far easier to catch if they do slip through.

Known Affected npm Packages

The following is a partial list of confirmed compromised packages identified during the Shai-Hulud 2.0 attack. Security researchers continue to identify additional affected packages. Organizations should audit their dependencies immediately.