How To Use npm Packages Without Risking Your Pipeline

Key takeaways

1. Every npm install is a trust decision. When you run npm install, you're executing code from the internet on your machine. The npm registry has no gatekeeping - any account with publish access can release a new version of a trusted package.
   
2. Pinning to a specific version does not protect you from supply chain attacks. Attackers publish malicious code under legitimate version numbers of trusted packages. A pinned version that was clean yesterday can be replaced with a compromised one today.
   
3. The Shai-Hulud worm and Mini Shai-Hulud campaign represent a new class of npm threat - self-propagating malware that spreads from project to project by harvesting npm publish tokens from compromised CI environments and using them to release new malicious versions automatically.
   
4. npm supply chain attacks now routinely target packages with tens or hundreds of millions of weekly downloads. The risk is no longer theoretical or limited to obscure packages - it lives in the dependencies your applications almost certainly use today.
   
5. Echo Libraries acts as a transparent, trusted npm source. Developers continue using npm install exactly as they do today - Echo silently blocks malicious and vulnerable package versions before they can be pulled, with critical CVEs patched within 7 days under a strict SLA.
   

What is an npm library

npm - the Node Package Manager - is the world's largest software registry, hosting over two million packages that JavaScript and Node.js developers use to build applications. An npm library is any reusable block of code published to that registry: a utility, a framework, an SDK, a helper function. When a developer runs npm install axios or npm install react, they're pulling an npm library into their project.

The npm ecosystem is one of the most powerful accelerants in software development. Instead of writing every function from scratch, teams compose applications from hundreds of existing libraries - authentication, HTTP requests, data parsing, UI components, testing utilities. A typical Node.js application has anywhere from dozens to thousands of transitive dependencies: packages that your direct dependencies depend on, which in turn depend on others.

That dependency depth is what makes npm libraries so valuable - and so consequential from a security standpoint. A vulnerability or malicious payload in a single widely used library doesn't affect one application. It affects every application that depends on it, directly or transitively, across every team that ran npm install while that version was available.

The problem with updating npm modules today - the risk of pinning to latest

The conventional wisdom in dependency management is to keep your npm modules updated. In theory, updating npm modules regularly means you get security patches, bug fixes, and performance improvements as they're released. In practice, the update process itself has become a risk surface.

Pinning to latest is not a safety net - it's an exposure.

When a package is configured to pull latest, every new release of that package is automatically trusted. If a maintainer's account is compromised and a malicious version is published, any environment configured to pull latest installs it immediately, automatically, with no human review.

But pinning to a specific version doesn't fully protect you either. Attackers have demonstrated that they can publish malicious code under new semver-compliant version numbers - meaning a package that was clean at version 1.13.4 can have a compromised 1.14.1 appear in the registry at any time. If your update process evaluates new patch or minor releases as safe by default, you're still exposed.

The update cycle itself creates repeated moments of exposure:

• Dependabot and automated PR tools open pull requests for new package versions. Each one is an attack surface if the new version is malicious.
• npm install in CI pipelines resolves dependency ranges on every build. A range like ^1.13.0 will automatically resolve to the latest compatible version - including a malicious one published after your package-lock.json was last committed.
• Developer machines running npm install without a lockfile, or with an outdated one, are silently exposed to whatever is currently in the registry.

The result is that the act of staying up to date - which is exactly what security teams ask developers to do - is one of the primary mechanisms by which npm supply chain attacks spread.

npm malware news - the attacks you need to know about

The threat landscape for npm malware has shifted dramatically in the past twelve months. It's no longer about typosquatted packages with names designed to fool inattentive developers. The attacks making headlines in 2026 are targeting the packages your team already uses and trusts - compromising them at the source.

The Shai-Hulud worm and Mini Shai-Hulud campaign

In September 2025, a self-propagating worm called Shai-Hulud appeared in the npm ecosystem - named after the sandworm from Dune. Its defining characteristic was autonomy: rather than requiring an attacker to manually publish malicious packages, the worm spread by stealing npm publish tokens from compromised CI environments and using them to automatically release malicious versions of packages whose maintainers had publish access. Hundreds of packages were affected.

The group known as TeamPCP - also responsible for breaches at Trivy and Bitwarden - subsequently launched Mini Shai-Hulud, a more advanced evolution of the same technique. In May 2026, TeamPCP open-sourced the worm's tooling on GitHub, effectively making the attack methodology available to anyone. Attribution for subsequent incidents using the same techniques is no longer possible - the pattern itself is the threat.

TanStack - 84 malicious versions, no tokens stolen

In May 2026, attackers published 84 malicious versions across 42 TanStack packages - a React ecosystem with millions of weekly downloads. What made this incident notable was the attack chain: a pull_request_target exploit, GitHub Actions cache poisoning, and OIDC token extraction from runner process memory. No passwords or npm tokens were stolen. The attackers hijacked the trusted publishing pipeline itself, producing artifacts that were signed and attested by legitimate infrastructure.

Because TanStack packages are installed as dependencies in other projects' CI pipelines, the worm harvested tokens from those build environments and propagated autonomously - publishing malicious versions of every package whose maintainer had publish access.

The Axios npm supply chain attack - 1.8 million malicious downloads

Attackers published malicious versions of axios - a package with approximately 100 million weekly downloads - as versions 1.14.1 and 0.30.0. The axios npm supply chain attack resulted in approximately 1.8 million malicious downloads before the versions were taken down. There was no corresponding GitHub tag for either release. The publisher changed from the project's trusted CI to a manual account. No build attestations were present. None of these signals were visible to a developer running npm install axios.

Red Hat Cloud Services - 30+ packages through legitimate infrastructure

More than 30 official Red Hat Cloud Services npm packages were compromised and distributed through Red Hat's own legitimate CI/CD pipeline. Attackers gained access to a developer account - likely via an infostealer - injected malicious GitHub Actions workflows, obtained OIDC tokens through trusted publishing, and released backdoored packages under official Red Hat package names. The packages collectively received more than 100,000 downloads per week.

323 packages in 22 minutes

Following a single maintainer account compromise, 323 malicious npm packages were published in under 22 minutes - a demonstration of how quickly a single point of failure in the publish chain can produce ecosystem-wide exposure.

The common thread across all of these incidents: the packages were trusted, the publishers appeared legitimate, and the artifacts in some cases were signed. Nothing in a standard npm install workflow would have indicated anything was wrong.

How npm supply chain attacks actually work

Understanding the mechanics makes it clear why traditional defenses fall short.

Step 1 - Gaining publish access

Attackers need the ability to publish to a legitimate package. The methods vary:

• Infostealer malware on a developer or maintainer's machine harvests stored npm tokens, which are then used to publish directly
• Phishing or account compromise gives the attacker direct access to the npm account
• CI/CD pipeline compromise - as in TanStack and Red Hat - gives the attacker the ability to trigger a publish through the project's own legitimate automation, without ever needing the maintainer's credentials directly
• OIDC token abuse - in pipelines using trusted publishing, an attacker with access to the CI runner can extract the OIDC token used to authenticate to npm and use it to publish a new version

Step 2 - Publishing the malicious version

The attacker publishes a new version under the legitimate package name. It may be a minor semver bump (1.13.4 → 1.14.1) designed to be picked up by automated update tools. The payload is typically embedded in:

• postinstall scripts - code that executes automatically at install time, before the package is ever imported into application code
• The package source itself - malicious code injected into the library's main module, executing when the package is imported

The payload targets credentials and secrets that are commonly present in developer and CI environments: npm and GitHub tokens, AWS/GCP/Azure credentials, Kubernetes configs, SSH keys, Docker credentials, .env files.

Step 3 - Automated distribution

Once the malicious version is in the registry, distribution is handled by the same automation that makes npm so productive:

• Pipelines running npm install resolve dependency ranges and pull the new version
• Dependabot and automated update tools see a new version and open PRs or apply it automatically
• Developer machines running npm install with a version range in package.json pull it silently

Step 4 - Propagation

In worm-style attacks like Shai-Hulud, the malware doesn't stop at credential theft. It uses the harvested npm publish tokens to publish malicious versions of other packages the compromised maintainer has access to - spreading autonomously from project to project without further attacker intervention.

Why traditional defenses don't stop it

• npm audit only catches vulnerabilities that have been reported and added to the npm advisory database - a newly published malicious version won't appear there until it's been identified and reported, which happens after exposure
• Signing and provenance prove where a package was built - not whether the build environment was clean or the code is safe. A signed artifact from a compromised pipeline is still malicious.
• Pinning versions prevents automatic updates but doesn't protect against malicious versions published at a new semver number, or against a version that was clean when pinned and is now being replaced

The alternative to open source npm packages

The answer to the npm malware threat isn't to stop using open source. That's not a realistic option for any modern development team. The answer is to stop treating the public npm registry as a direct source of truth for what enters your environment.

Echo Libraries provides a trusted, continuously maintained npm artifact source - a pipeline where malicious and vulnerable package versions are blocked before they're ever available to pull. Rather than running npm install directly against the public registry, your environment pulls from Echo's vetted source, where every package version has been independently processed before it's made available.

What that processing covers:

• Malware sandboxing - every package version is executed in an isolated environment to detect malicious install scripts and post-install hooks before it's available to your environment
• CVE remediation - critical and high vulnerabilities are patched on the exact version your package.json requires, without changing the version number or breaking your dependency tree
• Upstream health monitoring - publisher account changes, release cadence anomalies, and pipeline irregularities are monitored continuously; versions that show compromise signals are quarantined before they're pullable
• Independent provenance attestation - libraries are built and signed on Echo's own secure infrastructure, separate from the original maintainer's pipeline
• SBOM and VEX delivery - audit-ready documentation of what's in every package and what's been remediated

This covers the attack vectors that traditional defenses miss: a malicious postinstall script is caught in the sandbox before it reaches any developer machine or CI environment. A compromised new version published under a legitimate semver bump is quarantined before it appears in your artifact source. A package whose publisher account just changed to an unfamiliar actor is flagged before any team pulls it.

How Echo protects every npm install

The most important thing to understand about Echo's approach is what it doesn't change.

Developers continue using npm install exactly as they do today. The same package names. The same version numbers. The same package.json and package-lock.json workflow. No new CLI tools. No new commands to learn. No changes to CI pipelines beyond a one-time configuration to point at Echo's registry endpoint.

From the developer's perspective, nothing is different. From the security team's perspective, everything is.

Under the hood, when a developer or CI pipeline runs npm install axios, the request goes to Echo's vetted artifact source instead of the public npm registry. Echo has already:

• Verified that the version being requested is clean - no malicious install scripts, no known malicious payloads
• Patched any critical or high CVEs present in that version, under a strict 7-day SLA for critical vulnerabilities
• Confirmed that the package's provenance is consistent with the expected publisher and build pipeline
• Checked that no upstream compromise signals have been detected for that package or maintainer

If a version fails any of these checks, it's blocked. The developer or pipeline gets a clear message that the version is unavailable through Echo's trusted source - not a silent install of compromised code.

When the Axios npm supply chain attack occurred, the compromised versions simply didn't exist in Echo's artifact source. Echo customers ran npm install axios and got the clean version, exactly as they expected. The attack was invisible to them - not because it was detected and quarantined reactively, but because the malicious version was never available to pull.

As one CISO put it: "With all of the recent supply chain attacks, it seemed everyone was scrambling to mitigate. But since we were using Echo libraries, our team was completely calm knowing that we weren't affected."

Echo integrates directly with Nexus, JFrog Artifactory, GitHub Packages, and other internal registries - so the vetted artifact source slots into your existing infrastructure without re-architecting anything. For the full picture of how Echo Libraries works, visit echo.ai/product/libraries. And for context on the specific incidents covered in this post, see our detailed breakdown of the March 2026 supply chain attacks.

FAQ

What is an npm library and why does it matter for security?

An npm library is a reusable JavaScript or Node.js package published to the npm registry. When you run npm install, you're executing code from the internet - often hundreds of packages deep through transitive dependencies. Security matters because a single compromised library can propagate malicious code across every application that depends on it. The npm registry has no publish-time gatekeeping, meaning any account with access can release a new version of a trusted package at any time.

What is the Shai-Hulud npm worm?

Shai-Hulud is a self-propagating npm worm that appeared in September 2025. Rather than requiring manual attacker action for each compromise, it spread autonomously - stealing npm publish tokens from CI environments and using them to release malicious versions of packages the compromised maintainer had access to. A more advanced campaign called Mini Shai-Hulud followed, and in May 2026 its source code was open-sourced by TeamPCP, making the attack methodology available to any actor. The pattern, not any individual group, is now the persistent threat.

Why doesn't pinning npm versions protect against supply chain attacks?

Pinning a version locks your dependency to a specific semver number, which prevents automatic updates to newer potentially compromised versions. But it doesn't protect against attackers publishing malicious code under a new legitimate-looking version number, and it doesn't protect against postinstall script attacks in versions that were clean when you pinned them. More importantly, most CI pipelines and development workflows use version ranges - ^1.13.0 resolves to whatever the latest compatible version is at install time, including malicious new releases.

How does Echo Libraries protect against npm supply chain attacks?

Echo operates as a transparent, trusted artifact source that sits between your npm install commands and the public registry. Every package version is sandboxed for malicious behavior, has critical and high CVEs patched under a 7-day SLA, and is monitored for upstream compromise signals - before it's made available to pull. Malicious versions are blocked entirely. Developers and CI pipelines see no change in workflow; the protection is invisible until it blocks something, at which point the version simply isn't available rather than silently installing compromised code.

What should my team do if we ran npm install during a known attack window?

Treat any environment that ran npm install during the window as potentially compromised. Rotate all credentials immediately - npm tokens, GitHub tokens, AWS/GCP/Azure keys, SSH keys, and any other secrets present in that environment. Audit Kubernetes secrets and cloud IAM access. Review CI logs for unexpected outbound connections. Scan for the specific malicious package versions using advisories like GHSA identifiers published for the incident. Going forward, using a vetted artifact source like Echo means you won't need to make that assessment after the fact.