How Did the September npm Maintainer Account Compromise Happen and What Can We Learn from it?

In September 2025, a sophisticated phishing campaign led to one of the most impactful npm maintainer account compromises to date. It affected billions of weekly downloads and thousands of dependent projects, highlighting how security vulnerabilities can stem from the trust placed in maintainers and widely used dependencies.

TL;DR: What Happened in the npm Maintainer Account Compromise?

• Attackers phished Josh Junon (also known as qix), a well-known npm package developer, via a fake 2FA reset email impersonating npm Support.
• Malicious updates were published to chalk, strip-ansi, ansi-styles, supports-color, and related packages, injecting code that could hijack cryptocurrency transactions in applications accessed via the web.
• These tools were widely used dependencies, allowing updates to spread automatically across thousands of projects and CI/CD pipelines. It demonstrated how a single npm maintainer account compromise can create cascading risks across projects.

What to do now:

Stronger developer security, signed builds, pinned versions, and SBOM verification can help to reduce your exposure. Monitoring for unusual publishing activity or maintainer changes can also help detect attacks earlier.

What Led to the npm Maintainer Account Compromise?

The compromise began when Junon was tricked into entering his credentials and 2FA code on a convincing phishing page that appeared to be an npm Support portal. The phishing email came from support [at] npmjs [dot] help, impersonating the npmjs.com domain. It was part of a larger campaign targeting package maintainers and developers.

The attackers used Junon’s credentials to log into his maintainer account and publish malicious versions of several high-traffic packages, including chalk, supports-color, ansi-styles, and strip-ansi. The malicious code was designed to monitor network traffic for cryptocurrency transactions and replace destination wallet addresses with addresses controlled by the attackers.

Why the Impact Reached So Many Projects

All of these packages run deep within CLI tooling and developer workflows, and developers depend on them as transitive dependencies across many projects. The result was rapid propagation through installations before most developers noticed anything unusual. Together, the packages generated 2.67 billion downloads per week, and that scale turned a single maintainer’s compromise into a major incident.

Practical Steps to Prevent Future Incidents

The guidelines below can help your team build resilience and reduce the likelihood of similar threats affecting your environment:

• Hardware-backed 2FA for maintainers: This improves developer security by requiring a physical security key for logins and publishing, which prevents account takeovers via phishing.
• Short-lived and scoped tokens for CI/CD: Don’t keep long-lasting npm tokens. Only give the token the permissions it really needs, for a short time, to reduce risk if it’s stolen.
• Dependency pinning + checksum validation: Locking packages to specific versions and verifying their integrity instead of installing automatic upgrades helps prevent the installation of tampered or malicious updates.
• Signed builds & attestation (SLSA/Cosign): Confirms that packages come from a trusted source code.
• SBOM generation and auditing: Tracks all dependencies (direct and transitive) to detect if a compromised package enters your environment.
• Alerts for sudden maintainer or package ownership changes: Detects suspicious activity quickly, e.g., if a popular package suddenly changes hands.
• CI/CD environment isolation & outbound network controls: Prevents malware from exfiltrating secrets from builds or developer machines.
• Human review or approval for critical package updates: Adds an extra check for widely used or high-risk packages before publishing updates.

Strengthening Your Defense Against Maintainer Account Attacks

The September npm compromise demonstrated how quickly a single maintainer breach can impact the entire software supply chain. Strong identity controls, signed builds, dependency pinning, SBOM auditing, and human oversight are essential for reducing your exposure. Attacks targeting maintainers will continue, but teams that combine these best practices with continuous monitoring can significantly limit their risk. Now is the time to reinforce these controls before the next compromise hits.

FAQ: Understanding the npm Maintainer Account Compromise

​​How does this attack differ from other npm supply chain attacks?

This attack affected one maintainer account, using widely used CLI packages and leveraging transitive dependencies to propagate malicious updates rapidly. Unlike broader attacks that exploit multiple maintainers or large-scale credential leaks, the incident spread through trusted, high-impact packages embedded deeply in developer workflows. That level of trust and integration made detection and containment particularly challenging.

Why was the npm ecosystem so vulnerable to a single maintainer’s compromise?

Weaknesses in open-source software security and dependency management allowed a single compromised maintainer account to propagate malicious code through transitive dependencies. This attack impacted thousands of projects that relied on the affected packages.

Can SBOMs fully protect against npm security vulnerabilities?

No. SBOMs can reduce the risk of npm security vulnerabilities by enhancing visibility and supporting dependency management, but they cannot prevent them entirely. Teams must combine them with strong identity controls and signed builds to reduce open-source software security risks and prevent attacks.