Another week, another npm supply chain attack — except this one hit different. On October 22nd, the widely-used ua-parser-js package was compromised when an attacker gained access to the maintainer’s npm account and published three malicious versions (0.7.29, 0.8.0, and 1.0.0). The package has over 7 million weekly downloads and is used by companies including Facebook, Amazon, Microsoft, Google, and Slack.
The malicious versions contained scripts that downloaded and executed cryptominers on Linux systems and both cryptominers and credential-stealing trojans on Windows. If your CI/CD pipeline, development environment, or production system pulled one of these versions between the time of publication and npm’s takedown, you may have been compromised.
I’ve been writing about supply chain security for months now, and every new incident makes the same point more forcefully: our dependency on the npm ecosystem is a systemic risk that we are not adequately addressing.
The Attack Vector#
The attack followed a pattern we’ve seen before: account takeover of a legitimate maintainer. The attacker didn’t create a typosquatted package or a malicious new library. They hijacked an established, trusted package with millions of users and years of history. This is the supply chain equivalent of breaking into a bank vault rather than setting up a fake ATM.
The malicious payload was straightforward but effective:
- A preinstall script that executed platform-specific binaries
- On Linux: a cryptominer binary
- On Windows: a cryptominer plus a DLL that harvested credentials from browsers and sent them to a remote server
The versions were live on npm for approximately four hours before being identified and pulled. Four hours doesn’t sound like much, but consider how many CI/CD pipelines run during a workday. How many npm install commands execute across the world in four hours. How many Docker images get built with npm ci as a step. The blast radius of even a brief compromise of a popular package is enormous.
The compromised versions were 0.7.29, 0.8.0, and 1.0.0. Clean versions (0.7.30, 0.8.1, and 1.0.1) were published shortly after. If you use ua-parser-js, check your lock files immediately.
Why This Keeps Happening#
The fundamental problem is that npm’s security model puts enormous trust in individual maintainer accounts, and those accounts are often protected by nothing more than a password. The ua-parser-js maintainer, Faisal Salman, confirmed that his account was compromised — likely through credential reuse or a phishing attack.
npm has offered two-factor authentication for years, but adoption remains low. And even 2FA doesn’t prevent all account takeover scenarios — session hijacking, OAuth token theft, and social engineering attacks against npm support can all bypass it.
But the account security issue is only the surface problem. The deeper issues are architectural:
Implicit trust in updates: When you specify "ua-parser-js": "^0.7.28" in your package.json, you’re saying “I trust any future 0.7.x release.” Your lock file protects you on npm ci, but npm install will happily pull a new matching version. And many teams use npm install in their Dockerfiles and CI pipelines.
No code review for published packages: Anyone with publish access can push arbitrary code to npm. There’s no review process, no signature verification by default, no diff between versions shown to consumers. You get what you get.
Massive dependency trees: A typical Node.js application has hundreds or thousands of transitive dependencies. You may never have heard of ua-parser-js, but there’s a good chance something in your dependency tree uses it. The npm ls ua-parser-js command might surprise you.
Practical Defenses#
After the initial panic, the practical question is: what can we actually do about this? Here’s what I’m recommending to teams right now:
Lock files are non-negotiable. Always use npm ci in CI/CD pipelines, never npm install. The lock file pins exact versions and integrity hashes. If someone publishes a compromised version, your builds won’t pull it as long as your lock file hasn’t been updated.
Audit dependencies regularly. Run npm audit as a CI step. It’s not perfect — it only catches known vulnerabilities, not active compromises — but it’s a baseline. Consider tools like Socket or Snyk that do deeper behavioral analysis of packages.
Review dependency updates before merging. When Dependabot or Renovate creates a PR to update a package, actually look at what changed. For direct dependencies, check the changelog and the diff. For a package like ua-parser-js, a new preinstall script downloading binaries should be an obvious red flag.
Consider using a private registry or proxy. Tools like Verdaccio, Artifactory, or npm Enterprise let you control which packages and versions are available to your team. You can implement an allowlist, delay propagation of new versions, or require manual approval for updates to critical packages.
Minimize your dependency surface. Do you really need that package? For something like user-agent parsing, consider whether a simple regex or a smaller, more focused package might suffice. Every dependency is an attack surface.
The Broader Pattern#
This is the third major npm supply chain incident in recent months, following the coa and rc compromises that happened around the same time. The pattern is clear: attackers have realized that compromising a single popular npm package gives them access to thousands of downstream projects simultaneously.
The npm registry serves billions of downloads per week. It’s critical infrastructure for the global software supply chain. And it’s secured, fundamentally, by individual maintainers choosing good passwords and enabling 2FA.
We need systemic solutions. npm’s recent acquisition by GitHub (and by extension, Microsoft) gives them the resources to implement stronger controls — mandatory 2FA for popular packages, automated behavioral analysis of new versions, signing and provenance attestation. Some of these are in progress. They need to ship faster.
My Take#
Every time I write about a supply chain attack, I feel like I’m repeating myself. And I am, because the underlying dynamics haven’t changed. We’re building our software on foundations we don’t control, maintained by people we don’t know, secured by mechanisms we don’t verify.
I don’t say this to blame maintainers — Faisal Salman maintains ua-parser-js as a side project, and he responded quickly and transparently once the compromise was identified. The problem is structural. We’ve built an ecosystem where individual volunteers are single points of failure for critical infrastructure used by the world’s largest companies.
Until the ecosystem builds better guardrails — and until developers take dependency management seriously as a security concern — these incidents will keep happening. Lock your dependencies. Audit your supply chain. And maybe think twice before adding that next npm install.
Part of the Security in Practice series. Previous entries have covered the Confluence RCE, OMIGOD vulnerability, and the OWASP Top 10 2021 update. Supply chain security remains the defining challenge of modern software development.