Inside the Largest NPM Hack in History: How a Catastrophe Was Narrowly Avoided

On September 8, 2025, the JavaScript ecosystem faced one of its most significant supply chain attacks. A phishing campaign compromised the npm account of maintainer Josh Junon (~qix), allowing attackers to push malicious updates to 18 widely used packages including chalk, debug, and ansi-styles with over 2.6 billion weekly downloads full list available here (Palo Alto Networks, 2025).

This breach shows how one hacked account can put millions of developers at risk, but it also proves that fast action can stop a bad situation from turning into a disaster. It’s a wake-up call about the growing dangers of supply chain attacks in today’s software world, and why taking a prevention-first approach is no longer optional.

For anyone writing JavaScript, this wasn’t just news on a screen, it was a reminder of how easily our own projects could be affected.

This post will cover what went wrong, the impact, and lessons learned.

Timeline of the Breach

According to a report by Palo Alto Networks (2025), the phishing email disguised as a support request from npmjs.help, tricked Junon into disclosing credentials. Once inside, attackers updated multiple packages he maintained, some with over 1 billion monthly downloads.

Screenshot of Junon’s Bluesky post confirming phishing-based compromise on Sept 8, 2025. — Figure 1. Screenshot of Josh Junon’s Bluesky post confirming his npm account was compromised via a phishing email (September 8, 2025).

Fortunately, detection was swift. Aikido Security (2025) reports:

Minutes: Aikido’s monitoring flagged malicious code.
5 minutes: Junon was alerted.
Hours: Compromised packages were removed.
Ongoing: Security audits across the ecosystem.

Four-stage timeline—phishing (Sept 5–8), maintainer compromised (Sept 8, 13:16 UTC), malicious packages published (minutes later), detection & containment (minutes–hours). — Figure 2. Timeline of the npm supply chain attack (September 8, 2025). Created by the author

The speed of response underscored both the effectiveness of monitoring tools and the narrow window for preventing disaster. This chain of events shows how quickly one stolen account can spiral into a system-wide threat, and it’s a reminder that spotting the problem early often makes the difference between a close call and a disaster.

Technical Details: How the Breach Happened

The root cause was phishing. Attackers registered npmjs.help days earlier and used it to harvest credentials. They injected obfuscated JavaScript designed to:

Hook key functions (fetch, wallet APIs).
Scan for wallet addresses and transaction data.
Rewrite transactions with attacker-controlled addresses.
Hijack funds silently while masking changes.

ReversingLabs (2025) reported that more than 550 GitHub files were linked to the malware which targeted Ethereum, Bitcoin, Solana, and other blockchains. Tomislav Peričin, co-founder of ReversingLabs, warned that:

“There’s no one building code with npm packages that isn’t possibly affected by this.”

Since the malware worked inside core wallet functions, the usual defences around the network weren’t enough. Real protection depends on stronger account security and checks that confirm packages haven’t been tampered with.

Impact of the Breach

According to the United Nations University (2025), the malware caused almost no direct losses, only a few cents stolen before it was removed, but the potential consequences could have been staggering.

Millions of compromised applications.
Theft across cryptocurrency wallets and DeFi protocols.
Loss of trust in the npm ecosystem.
Cascading failures in business-critical systems.

The outcome proved that even short delays in detection could have led to global fallout.

Lessons Learned & Best Practices

This breach highlights how fragile open-source ecosystems can be. To mitigate risks, developers and organizations should:

Pin package versions and use lock files.
Audit dependencies and clear caches after incidents.
Reinstall packages from trusted sources only.
Adopt frameworks like NIST or ISO 27001 for supply chain security.
Require phishing-resistant MFA for maintainers.
Enable package integrity verification (e.g., npm audit, npm ci with lockfile verification).
Use Sigstore/cosign to sign and verify build artifacts.

The lesson is simple: trust is not enough. Audit, update, and defend.

Conclusion

The largest npm hack in history began with a phishing email and ended as a near miss. Actual damages were negligible, but the potential destruction was immeasurable.

This is a warning for everyone who depends on open source: without stronger supply chain security, the next attack may not be contained in time.

Should stricter requirements be imposed on open-source maintainers, or would that undermine collaboration?