The open source ecosystem continues to face organized, adaptive supply chain threats that spread through compromised credentials and malicious package lifecycle scripts. The most recent example is the multi-wave Shai-Hulud campaign.

While individual incidents differ in their mechanics and speed, the pattern is consistent: Adversaries learn quickly, target maintainer workflows, and exploit trust boundaries in publication pipelines.

This post distills durable lessons and actions to help maintainers and organizations harden their systems and prepare for the next campaign, not just respond to the last one. We also share more about what’s next on the npm security roadmap over the next two quarters. 

Recent Shai-Hulud Campaigns

Shai-Hulud is a coordinated, multi-wave campaign targeting the JavaScript supply chain and evolved from opportunistic compromises to engineered, targeted attacks.

The first wave focused on abusing compromised maintainer accounts. It injected malicious post install scripts to slip malicious code into packages, exfiltrate secrets, and self-replicate, demonstrating how quickly a single foothold can ripple across dependencies. 

The second wave, referred to as Shai-Hulud 2.0, escalated the threat: Its ability to self-replicate and spread via compromised credentials was updated to enable cross-victim credential exposure. The second wave also introduced endpoint command and control via self-hosted runner registration, harvesting a wider range of secrets to fuel further propagation, and destructive functionality. This wave added a focus on CI environments, changing its behavior when it detects it is running in this context and including privilege escalation techniques targeted to certain build agents. It also used a multi-stage payload that was harder to detect than the previous wave payload. The shortened timeline between variants signals an organized adversary studying community defenses and rapidly iterating around them.

Rather than isolated breaches, the Shai-Hulud campaigns target trust boundaries in maintainer workflows and CI publication pipelines, with a focus on credential harvesting and install-time execution. The defining characteristics we see across waves include:

• Credential-adjacent compromise: Attackers gain initial footholds via compromised credentials or OAuth tokens, then pivot to collect additional secrets (npm tokens, CI tokens, cloud credentials) to expand reach. This enables reuse across organizations and future waves without a single point of failure.
• Install-time execution with obfuscation: Malicious post-install or lifecycle scripts are injected into packages (or dependency chains) and only reveal behavior at runtime. Payloads are often conditionally activated (e.g., environment checks, org scopes) and exfiltrate data using techniques tailored to the environment it is running in.
• Targeting trusted namespaces and internal package names: The campaign affected popular and trusted packages, and the worm published infected packages with existing package names. The second wave also patched the version number of the package to make the infected packages look like legitimate updates and blend in with normal maintainer activity.
• Rapid iteration and engineering around defenses: Short intervals between variants and deliberate changes to bypass previous mitigations indicate an organized campaign mindset. The goal is durable access and scalable spread, not one-off opportunism.
• Review blind spots in publication pipelines: Differences between source and published artifacts, lifecycle scripts, and build-time transformations create gaps where injected behavior can land without notice if teams lack artifact validation or staged approvals.

Recent waves in this pattern reinforce that defenders should harden publication models and credential flows proactively, rather than tailoring mitigations to any single variant.

What’s Next for npm

We’re accelerating our security roadmap to address the evolving threat landscape. Moving forward, our immediate focus is on adding support for:

• Bulk OIDC onboarding: Streamlined tooling to help organizations migrate hundreds of packages to trusted publishing at scale.
• Expanded OIDC provider support: Adding support for additional CI providers beyond GitHub Actions and GitLab.
• Staged publishing: A new publication model that gives maintainers a review period before packages go live, with MFA-verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years.

Together, these investments give maintainers stronger, more flexible tools to secure their packages at every stage of the publication process.

Advice for GitHub and npm users and maintainers

Malware like Shai-Hulud often spreads by adding malicious code to npm packages. The malicious code is executed as part of the installation of the package so that any npm user who installs the package is compromised. The malware scavenges the local system for tokens, which it can then use to continue propagating. Since npm packages often have many dependencies, by adding malware to one package, the attacker can indirectly infect many other packages. And by hoarding some of the scavenged tokens rather than using them immediately, the attacker can launch a new campaign weeks or months after the initial compromise.

In the “References” section below, we have included links to longer articles with analysis of recent campaigns and advice on how to stay secure, so we won’t rehash all of that information here. Instead, here is a short summary of our top recommendations:

Advice for everyone

• Enable phishing-resistant MFA on all your accounts, particularly for GitHub package managers like npm, PyPI, RubyGems, or NuGet, and also any accounts that could be leveraged for account takeover or phishing, like email and social media accounts.
• Always set an expiration date on tokens to ensure that they’re rotated on a regular schedule. Organizations can enforce a maximum lifetime policy.
• Audit and revoke access for unused GitHub/OAuth apps.
• Use a sandbox, such as GitHub Codespaces or a virtual machine or container, for development work. This limits the access of any malware that you accidentally run.

Advice for maintainers

• Enable branch protection so that malicious updates cannot be pushed directly to your main branch, even if the attacker has access to a valid token.
• Use npm trusted publishing instead of tokens. Trusted publishing is also available for other package managers such as PyPI, RubyGems, and NuGet.
• Pin CI dependencies, enable code scanning, and don’t forget to resolve the code scanning alerts!
• Monitor package artifacts and validate published tarballs/bundles against source (e.g., SRI or artifact build attestations).

Note that the above advice is preventative. If you believe you are a victim of an attack and need help securing your GitHub or npm account, please contact GitHub Support.

References

• Report a malicious package in npm
• Our plan for a more secure npm supply chain
• Strengthening npm security
• View malware advisories in the Advisory Database
• Quickstart for securing your repository 
• Dependency review on GitHub
• OpenSSF best practices for npm
• Microsoft’s guidance for detecting and defending
• Recent improvements to GitHub Actions

The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.

Open source software is the bedrock of the modern software industry. Its collaborative nature and vast ecosystem empower developers worldwide, driving efficiency and progress at an unprecedented scale. This scale also presents unique vulnerabilities that are continually tested and under attack by malicious actors, making the security of open source a critical concern for all. 

Transparency is central to maintaining community trust. Today, we’re sharing details of recent npm registry incidents, the actions we took towards remediation, and how we’re continuing to invest in npm security.

Recent attacks on the open source ecosystem

The software industry has faced a recent surge in damaging account takeovers on package registries, including npm. These ongoing attacks have allowed malicious actors to gain unauthorized access to maintainer accounts and subsequently distribute malicious software through well-known, trusted packages. 

On September 14, 2025, we were notified of the Shai-Hulud attack, a self-replicating worm that infiltrated the npm ecosystem via compromised maintainer accounts by injecting malicious post-install scripts into popular JavaScript packages. By combining self-replication with the capability to steal multiple types of secrets (and not just npm tokens), this worm could have enabled an endless stream of attacks had it not been for timely action from GitHub and open source maintainers. 

In direct response to this incident, GitHub has taken swift and decisive action including: 

• Immediate removal of 500+ compromised packages from the npm registry to prevent further propagation of malicious software.
• npm blocking the upload of new packages containing the malware’s IoCs (Indicators of Compromise), cutting off the self-replicating pattern.

Such breaches erode trust in the open source ecosystem and pose a direct threat to the integrity and security of the entire software supply chain. They also highlight why raising the bar on authentication and secure publishing practices is essential to strengthening the npm ecosystem against future attacks.

npm’s roadmap for hardening package publication

GitHub is committed to investigating these threats and mitigating the risks that they pose to the open source community. To address token abuse and self-replicating malware, we will be changing authentication and publishing options in the near future to only include:

1. Local publishing with required two-factor authentication (2FA).
2. Granular tokens which will have a limited lifetime of seven days.
3. Trusted publishing.

To support these changes and further improve the security of the npm ecosystem, we will:

• Deprecate legacy classic tokens.
• Deprecate time-based one-time password (TOTP) 2FA, migrating users to FIDO-based 2FA.
• Limit granular tokens with publishing permissions to a shorter expiration.
• Set publishing access to disallow tokens by default, encouraging usage of trusted publishers or 2FA enforced local publishing.
• Remove the option to bypass 2FA for local package publishing.
• Expand eligible providers for trusted publishing.

We recognize that some of the security changes we are making may require updates to your workflows. We are going to roll these changes out gradually to ensure we minimize disruption while strengthening the security posture of npm. We’re committed to supporting you through this transition and will provide future updates with clear timelines, documentation, migration guides, and support channels.

Strengthening the ecosystem with trusted publishing

Trusted publishing is a recommended security capability by the OpenSSF Securing Software Repositories Working Group as it removes the need to securely manage an API token in the build system. It was pioneered by PyPI in April 2023 as a way to get API tokens out of build pipelines. Since then, trusted publishing has been added to RubyGems (December 2023), crates.io (July 2025), npm (also July 2025), and most recently NuGet (September 2025), as well as other package repositories. 

When npm released support for trusted publishing, it was our intention to let adoption of this new feature grow organically. However, attackers have shown us that they are not waiting. We strongly encourage projects to adopt trusted publishing as soon as possible, for all supported package managers.

Actions that npm maintainers can take today

These efforts, from GitHub and the broader software community, underscore our global commitment to fortifying the security of the software supply chain. The security of the ecosystem is a shared responsibility, and we’re grateful for the vigilance and collaboration of the open source community. 

Here are the actions npm maintainers can take now:

• Use npm trusted publishing instead of tokens.
• Strengthen publishing settings on accounts, orgs, and packages to require 2FA for any writes and publishing actions.
• When configuring two-factor authentication, use WebAuthn instead of TOTP.

True resilience requires the active participation and vigilance of everyone in the software industry. By adopting robust security practices, leveraging available tools, and contributing to these collective efforts, we can collectively build a more secure and trustworthy open source ecosystem for all.

The post Our plan for a more secure npm supply chain appeared first on The GitHub Blog.