Supply-chain cyberattack on npm - How it occurred, what was affected, and how to protect yourself

22 Sep 2025, by Slade Baylis

At the beginning of the year in our “State of Cybersecurity” round-up, we talked about how one of the biggest threats that organisations were going to face was increasingly sophisticated phishing due to the adoption of AI. Unfortunately, this month that point was proven correct in one of the largest open-source supply chain attacks to date - that of a hacking campaign targeting npm, the world's largest software registry hosting hundreds of thousands of open source Node.js projects and JavaScript libraries.

Standing for “Node Package Manager”, npm is a package manager tool used primarily to find and manage Javascript code packages and dependencies within JavaScript applications.  On September 8th, , a successful cybersecurity attack compromised 18 widely used npm packages, which see in total over 2.6 billion downloads each week.  Fortunately, the malicious code only went two hours in total before being discovered and removed.  Whilst there hasn’t been any confirmation on the number of downloads that took place whilst the affected packages contained malicious code, it’s likely that they were downloaded at least millions of times. 

The source of the attack?  A simple convincing phishing email targeting one of the maintainers of several widely-used packages.  That’s all it took for this hack, with the potential to affect millions of people, to take place – and whilst it was caught early and fixed quickly, this just highlights the risk that phishing poses, especially in light of AI tools being used to create ever more convincing forgeries.

How did the attack occur, what was affected, and what did it aim to do?

Occurring on 8th September, 2025, the JavaScript ecosystem experienced a massive supply-chain attack, compromising 18 widely used packages.  These packages collectively see over 2.6 billion downloads each week, making this one of the most impactful supply-chain attacks, if not the largest to date.  The packages that were compromised - including chalk, debug, strip-ansi and ansi-styles - are utility libraries that are very commonly used within many front-end and back-end projects, which is why the scale of the attack was so large. 

Before we move onto talking about the attack-vector, first we’ll list the affected packages and versions so that you can know if you need to take action:

Source: Qualys | Enterprise Cyber Risk & Security Platform¹

Here is the timeline of the events as they unfolded:

• 11:44pm AEST: Malicious versions of these packages uploaded to npm via compromised account of one of the maintainers.
• 12:16am AEST: The npm community identifies the suspicious code and raises alerts about the potential breach.

• 1:15am AEST: The maintainer confirms that their account was compromised and alerts npm

• Over the next few hours: npm initiates takedown of affected packages, and locks the affected account while developers begin auditing dependencies.
• 5:59am AEST: The maintainer posts on Github that NPM has taken down all impacted package versions and they will work with them regarding recovering his account.

The root cause of the attack was quite simple and an ongoing threat that all organisation face, that of a simple phishing email.  The email posed as a two-factor reset reminder, posing as an official email from npm themselves.  The formatting was for all intents and purposes identical to the real email, with the only clue that it was malicious being that it used a different email address and domain name - that of support@npmjs.help - to send the email.  That domain was registered mere days before the attack for the express purpose of looking as legitimate as possible.

This highlights the incredible risk that phishing poses to everyone.  Especially in light of the advent of AI, wherein either public LLM (Large Language Models) like ChatGPT can be used to craft convincing and even targeted phishing attacks, or other open-source LLMs are instead used cybercriminals to craft phishing attacks if the built-in protections in public LLMs are able to stop them.

The attack itself aimed primarily to target users’ cryptocurrency transfers through their browsers, hooking into critical functions within the browser to intercept web traffic and cryptocurrency wallet interactions in real-time.  It looked for transactions over several formats, such as Bitcoin, Ethereum, Litecoin and Bitcoin Cash with the aim of rewriting the transaction targets to addresses controlled by the attacker. 

It was even smart enough to have a wide range of potential recipient addresses, comparing them against the original intended destination to see which address was the most similar and closest matching address, then using that address to decrease the chances of that swap from being noticed!  The change was also implemented in such a way as to avoid the address being changed within the UI (User Interface) which is displayed to the user, making it almost invisible and undetectable to the end-user/victim.

What’s the most concerning about this attack is that it highlights that any infected or compromised library could potentially target and manipulate data and transactions occurring elsewhere within the browser.

How to protect yourself from supply-chain attacks

With this attack in particular, the lesson couldn’t be any more clear - you need to always be vigilant against the threat of phishing attacks.  Just last month we touched on this in our Staying Safe from Social Engineering: Simulated Phishing Training article, which talked about mitigating the risks of a successful phishing attack by performing ongoing simulated phishing campaigns, tracking performance, and providing training to staff.

However, there are other lessons to learn as well, such as how to design the maintenance cycle for your systems.  How quickly should you update your systems when an update becomes available?  Compromises like these are usually discovered very quickly - in this case the breach was discovered within two hours - so maintenance schedules that look to review changes and updates before they’re applied could potentially prevent this sort of attack, only applying critical security updates immediately.

Have any questions about phishing or how to protect yourself from it?

If you have any questions about how to protect yourself from phishing attacks, monitoring your infrastructure for vulnerabilities, or ensuring your systems are managed and up-to-date, let us know!

You can contact us via email at sales@micron21.com or via phone on 1300 769 972 (Option #1).

Sources

1, Qualys, “When Dependencies Turn Dangerous: Responding to the NPM Supply Chain Attack”, <https://blog.qualys.com/vulnerabilities-threat-research/2025/09/10/when-dependencies-turn-dangerous-responding-to-the-npm-supply-chain-attack>