Open-source software supply chain attacks are increasingly effective, with malicious Node Package Manager (npm) packages surging as a primary vector for initial access into developer environments. Threat actors capitalize on the inherent trust developers place in open-source registries, utilizing tactics like typosquatting, dependency confusion, and account takeover to distribute malware. By burying malicious code within native preinstall or postinstall scripts, attackers can silently execute commands during routine development workflows, often bypassing traditional endpoint security controls. This blog tracks current threat actor activity within the npm ecosystem and offers actionable guidance for defending CI/CD pipelines and developer endpoints, including practical hardening measures and detection opportunities.

What is npm and Why It Matters to Your Organization

npm (Node Package Manager) is the default package manager for Node.js and the largest software registry in the world, hosting over 2.5 million packages with billions of weekly downloads. It serves as the central distribution mechanism for JavaScript and TypeScript libraries. When a developer runs npm install, the package manager resolves dependencies, downloads packages from the registry, and executes lifecycle scripts (such as preinstall and postinstall hooks) automatically.

This matters to organizations beyond their development teams. npm packages are embedded in CI/CD pipelines, build servers, production applications, and internal tooling. A compromised package does not just affect a single developer workstation. It can propagate through automated build systems, container images, and deployment pipelines within seconds.

Why Threat Actors Target the npm Ecosystem

Automatic Code Execution: npm’s postinstall hook mechanism executes arbitrary code during package installation without requiring the developer to import or call anything. The malicious code runs before the developer ever opens a file.

Transitive Trust: A single popular package can have hundreds of downstream dependents. Compromising one package can create access to other projects that depends on it, directly or transitively.

Caret Range Auto-Updates: Most JavaScript projects specify dependencies using caret ranges (e.g., ^1.14.0), meaning any new minor or patch version is automatically resolved on the next install. Attackers publishing a new patch version reach every project that runs npm install without any explicit update action.

CI/CD Integration: npm packages are installed in build pipelines, GitHub Actions runners, Docker builds, and cloud-hosted development environments. These systems often have access to production secrets, deployment credentials, cloud tokens, and code signing infrastructure.

Cross-Platform Reach: Node.js runs on Windows, macOS, and Linux. Attackers can deploy platform-specific payloads from a single entry point, as demonstrated in both the axios and Shai-Hulud campaigns.

Developer Workstation Access: Developer endpoints are high-value targets. They hold SSH keys, cloud credentials, API tokens, database connection strings, and access to source code repositories.

How npm Supply Chain Attacks Work

While each campaign has its own characteristics, npm supply chain attacks often follow a consistent pattern:

Initial Access. The attacker gains control of an npm maintainer account or CI/CD pipeline with publishing privileges. Common methods include credential phishing, token theft from a prior compromise, or exploitation of misconfigured GitHub Actions workflows. Once the attacker has publishing access, they can push new versions of legitimate packages without any visible change to the package’s repository, release page, or tag history.

Malicious Package Publication. The attacker publishes a new version of the targeted package with a malicious payload embedded in it. This can take several forms: injecting a phantom dependency that did not previously exist, modifying a preinstall or postinstall hook to execute attacker-controlled code, or force-pushing a mutable version tag to reference a malicious commit. In most cases, the trusted package’s core application logic is left untouched. The malicious code lives entirely in the install script or in a newly added dependency, making it invisible without inspecting the full dependency tree.

Automatic Execution. When a developer or CI/CD pipeline runs npm install, the package manager resolves the malicious version (often automatically via caret ranges), downloads it, and executes its lifecycle hooks without any user interaction. The install hook typically runs an obfuscated JavaScript dropper that determines the host operating system and retrieves a platform-specific payload from attacker-controlled infrastructure.

Payload Deployment and Persistence. The dropper delivers OS-specific payloads targeting Windows, Linux, and macOS. Common post-exploitation behaviors include credential theft, renaming system binaries to evade process name-based detection, establishing persistence through registry Run keys or startup items, staging Python or shell-based backdoors in temporary directories, and masquerading as legitimate system processes.

Command and Control. Deployed RATs beacon to C2 infrastructure on regular intervals using HTTP POST requests designed to blend with legitimate traffic. Observed tradecraft includes mimicking package registry traffic in POST bodies, using unusual User-Agent strings, and routing C2 through typosquatted domains resembling legitimate vendor infrastructure. Once established, the RAT typically supports host profiling, credential harvesting, arbitrary script execution, and follow-on payload delivery.

Recent Threat Activity

The npm ecosystem has experienced a sustained escalation in supply chain attacks. State-sponsored actors, criminal operators, and unattributed threat groups have run concurrent campaigns that compromised packages with billions of combined downloads, weaponized CI/CD trust relationships, and deployed self-replicating malware across developer environments. The following table summarizes major campaigns observed in recent months.

Behavioral Detection and Threat Hunting

The following table provides detection logic targeting behaviors common or significant across recent major npm supply chain attacks. As with any detection and hunting effort, the effectiveness of these approaches depends on how frequently similar activity occurs as part of normal business operations. We encourage organizations to hunt for each behavior and establish baselines before moving to alerting.

Hardening and Mitigation Recommendations

The campaigns documented above share a common thread: attackers are exploiting the trust model built into the npm ecosystem and the default behaviors of package managers. The postinstall hook mechanism, caret range version resolution, and the implicit trust placed in maintainer accounts create an attack surface that persists regardless of which specific package is compromised next. The following recommendations address both the immediate indicators from recent campaigns and the structural risks that enable them.

• Pin dependency versions and use lockfiles. Replace caret (^) and tilde (~) ranges with exact versions in package.json. Commit package-lock.json, yarn.lock, or pnpm-lock.yaml to version control and verify lockfile integrity before every build. This prevents automatic resolution of newly published malicious versions.
• Disable or sandbox npm install scripts. Run npm install –ignore-scripts in CI/CD pipelines where postinstall hooks are not required. For projects that need install scripts, use tools that sandbox script execution or audit which packages rely on lifecycle hooks before enabling them. The postinstall hook is a primary execution vector in many if the major npm supply chain attack from the past year.
• Audit GitHub Actions and CI/CD workflows. Pin GitHub Actions to full commit SHAs rather than mutable version tags. Tags can be force-pushed to reference malicious commits without changing the tag name, published date, or release page. This was the primary mechanism in the TeamPCP campaign against Trivy and Checkmarx. Review workflows for pull_request_target triggers, which can grant elevated permissions to external contributors.
• Implement OIDC hardening for cloud access from CI/CD. Restrict OIDC trust relationships between GitHub Actions and cloud providers (AWS, Azure, GCP) to specific repositories, branches, and workflow files. Remove standing privileges for high-risk IAM actions. The Nx compromise (UNC6426) abused GitHub-to-AWS OIDC trust to create administrator roles and exfiltrate S3 data within 72 hours.
• Maintain a Software Bill of Materials (SBOM). Inventory all npm dependencies, including transitive dependencies, across your organization. When a supply chain compromise is disclosed, an SBOM enables rapid scoping of exposure without manual dependency tree auditing.
• Restrict outbound network access from build environments. CI/CD runners and build servers should not have unrestricted outbound internet access. Limit egress to known-good registries and artifact repositories. Block outbound connections to webhook.site domains (used in Shai-Hulud for exfiltration) and monitor for curl POST requests to domains that do not match expected artifact repositories.

Conclusion

The npm ecosystem is no longer a peripheral attack surface. It is a primary initial access vector for state-sponsored actors and criminal operators alike. Threat actors have demonstrated operationally mature programs that compromise trusted packages, exploit CI/CD trust relationships, and deploy cross-platform malware at scale. The window between a malicious package publication and the first infection is measured in seconds, not hours.  The detection and hardening guidance in this blog provides a starting point. Organizations should integrate these controls into their existing workflows and continue to monitor the evolving threat landscape as new campaigns emerge.

Sources

• Mitigating the Axios npm supply chain compromise
• The npm Threat Landscape: Attack Surface and Mitigations (Updated May 1)
• North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package
• Supply Chain Compromise of axios npm Package
• Elastic releases detections for the Axios supply chain compromise
• The Axios npm supply chain incident: fake dependency, real backdoor
• Threat Brief: Widespread Impact of the Axios Supply Chain Attack
• “Shai-Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack
• Navigating the Shai-Hulud Worm 2.0
• Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack
• LiteLLM and Telnyx compromised on PyPI: Tracing the TeamPCP supply chain campaign
• When the Security Scanner Became the Weapon: Inside the TeamPCP Supply Chain Campaign
• TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions
• How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM
• What We Know About the NPM Supply Chain Attack
• Defending Against npm Supply Chain Attacks: A Practical Guide to Detection, Emulation, and Analysis
• Widespread Supply Chain Compromise Impacting npm Ecosystem
• Multiple Supply Chain Attacks against npm Packages
• UNC6426 Exploits nx npm Supply-Chain Attack to Gain AWS Admin Access in 72 Hours
• Defending Against npm Supply Chain Attacks: A Practical Guide to Detection, Emulation, and Analysis | Splunk
• How SentinelOne’s AI EDR Autonomously Discovered and Stopped Anthropic’s Claude from Executing a Zero Day Supply Chain Attack, Globally
• Advisory on Securing the Software Supply Chain and Development Workflows
• npm Under Siege: Evolving Supply Chain Threats
• Practical Package Security: The Unofficial Guide | Wiz Blog