Once again, the npm supply chain has been compromised, putting developers relying on these vital open source components at risk. On November 24th, a sophisticated attack that borrows techniques from the Shai-Hulud malware used in the npm hijacking this past September was discovered.

This is not an isolated incident. It’s a continuation of an existing campaign that is now abusing CI/CD pipelines, and GitHub automation to spread faster and steal more secrets than before.

This version of Shai-Hulud is even more dangerous, as the malware leverages self-replication techniques to spread as widely as possible, with an observed rate of roughly 1,000 repos impacted every 30 minutes. 

According to Wiz, over 700 packages on npm have been found compromised, with tens of thousands of repos impacted, including multiple from trusted organizations such as Zapier, ENS Domains, PostHog, and Postman.

How does the Shai-Hulud Attack Work?

The Shai-Hulud malware is designed to compromise as many npm packages as it can, by harvesting credentials, exfiltrating stolen data, and infecting more users’ packages to spread to new systems.

This starts when an infected package.json’s modified preinstall script points to setup_bun.js. Instead of installing the Bun JavaScript runtime like a user may expect and trust the script to do, it instead sets up the malware to run.

Once this setup has occurred, a , payload is executed and the attack chain moves to the next step: credential harvesting.

The malware searches for:

• GitHub Tokens
• Cloud Credentials
• npm Tokens
• API Keys
• Passwords

Once this data is found, data exfiltration begins, and the data is put into public GitHub repositories with the marker Sha1-Hulud: The Second Coming. 

In many observed cases, the malware also drops additional files into repositories and runners, including:

• cloud.json, contents.json, environment.json, and truffleSecrets.json containing stolen secrets and environment details
  
  
• A malicious GitHub Actions workflow file, often .github/workflows/discussion.yaml, which can turn GitHub Discussions into a remote-code-execution backdoor on a self-hosted runner installed on the victim’s machine

The attack expands to other systems by finding npm tokens in the environment, which it uses to publish compromised updates to any packages maintained by the user.

This two-pronged sharing process allows the attack to expand to other systems, and new systems running the attack to borrow GitHub tokens from repositories with the same marker, allowing the sharing of tokens with correct permissions.

If the malware loses its access to GitHub or npm, the malware will trigger data destruction on the compromised machine. This tactic prevents users and service providers like GitHub and npm from taking sweeping action to block hijacker access.

How can I stay protected against attacks like Shai-Hulud?

Step 1: Detect & Contain

In the short term, teams should take steps to check if they were impacted of this breach and work to contain or remediate any potential damage.

Scanning your code, repositories, and runners for IoCs, identifying which dependencies are coming directly from upstream without any validation or control layer.

Revoking and rotating GitHub, npm, and cloud credentials that may have been exposed, and locking down who and what is allowed to introduce new third-party code into your environment.

Temporarily restricting repository creation and workflow changes until you understand the scope of impact, and establishing a controlled, auditable path for how new dependencies are introduced going forward.

Step 2: Harden Your Pipelines and Make Remediation Predictable

In the long term, the influx of attacks like Shai-Hulud underscores the need for a new approach to open source security. Traditional strategies were built for a world where maintainers were trusted by default, releases were infrequent, and the risk of active compromise was low.

Teams that take an always-update approach to their open source CVE remediation have been put on notice. Every automatic update now represents a trust decision. When that trust is abused, the impact is immediate and widespread.

If someone were reliant on auto updates for one of the packages that was part of Sha1-Hulud: The Second Coming, you would have been impacted as soon as the update was pulled into your system, with zero user input on your end.

Teams can reduce some of this risk by doing things like version pinning, disabling automatic updates, and restricting how developers pull in packages, but none of these solutions solves the real issue or addresses why teams might have chosen auto-updates in the first place.

The real challenges teams face are structural:

1. Dependency Complexity: Modern applications depend on massive, deeply nested dependency graphs that cannot be simplified overnight and often cannot be simplified at all.
2. The Remediation Gap: Vulnerabilities accumulate faster than teams can safely upgrade, and “update everything” becomes a risky shortcut rather than a real solution.

This leaves teams in an impossible position. Manual patching is too slow. Auto-updating is too dangerous. And doing nothing isn’t an option.

The solution is not to reduce complexity. It is to make remediation predictable.

Teams need a way to apply fixes to the code they already run, without pulling in unknown upstream changes. They need deterministic, controlled remediation that gives them security without disruption.

That is the model Seal was built around.

Seal enables teams to close vulnerabilities in place, on the versions they already trust, without risky upgrades or emergency rewrites. Instead of gambling on upstream publishers, teams operate with a controlled patch layer they own.

Take Control of Your Open Source with Seal

When a team uses a Sealed version of an open source package, they no longer have to rely on risky upstream updates or slow, manual patching to eliminate CVEs. Instead, they can apply fixes with one-click patches that deliver only the code they actually need.

This means that once the immediate risk is contained, teams can use Seal to replace upstream trust with sealed, verified packages that are continuously maintained and monitored.

We create production-ready, CVE-free versions of the exact packages your team already runs, and give you the tools to apply those patches instantly. Your endless CVE backlog is gone in seconds, without any breaking changes or tedious manual upgrade processes. 

Seal libraries let you secure your open source code against supply chain attacks like this, as our approach is focused on patching previous versions of libraries or the transitive dependencies they use. We give you just the security fixes you need and nothing else, so your applications stay stable and predictable.

With Seal, critical and high-severity vulnerabilities are remediated under a 72-hour SLA, including for legacy and end-of-life components. During active supply chain incidents, this gives security and engineering teams a reliable, measurable path to stabilization without introducing new risk.

See it in action and book a demo today.