On March 30, 2026, a North Korean threat actor quietly published two poisoned versions of axios, one of the most widely used software libraries on the internet. Axios is downloaded over 100 million times per week. It is embedded in countless websites, internal business tools, and cloud applications. For two days, anyone who ran a software build that included axios may have installed a Remote Access Trojan on their systems without knowing it.
This was not a hack targeting a specific business. It was a supply chain attack: compromise one trusted tool, infect thousands of organisations simultaneously. And it has direct implications for Australian SMEs, even if you have never heard of axios.
What Is a Supply Chain Attack?
You lock your front door. You install cameras. You train your staff not to click suspicious emails. But what about the software your IT provider uses to manage your systems? Or the tools your website developer runs when they update your site? Or the internal applications your SaaS vendors build on top of?
A supply chain attack does not target you directly. It targets the tools and services you trust. If those tools are compromised, you are compromised too, and you will have no idea it happened.
This is exactly what occurred with axios. Google Threat Intelligence has attributed the attack to UNC1069, a financially motivated North Korea-linked threat actor active since at least 2018. The attacker did not break into axios by brute force. They compromised the personal npm account of a trusted project maintainer, changed the registered email to one they controlled, and published two new versions: axios@1.14.1 and axios@0.30.4.
Anyone who ran npm install during that window and pulled down either of those versions automatically installed malware alongside a legitimate software tool.
How the Attack Actually Worked
The sophistication of this attack is worth understanding because it illustrates exactly why traditional security controls do not catch these incidents.
The malicious versions of axios did not modify any of axios's actual source code. Everything the package was supposed to do still worked correctly. Instead, the attacker added a new hidden dependency called plain-crypto-js@4.2.1 to the package configuration. This dependency had one purpose: to run a script the moment the software was installed.
Within two seconds of installation, before the install process had even finished, the malware was already connecting to the attacker's server. It then acted as a RAT dropper, deploying a Remote Access Trojan on macOS, Windows, and Linux.
A Remote Access Trojan gives an attacker persistent, covert access to the infected machine. They can read files, steal credentials, monitor activity, and move through your network. The infection is silent and the legitimate axios package continues to work as expected, so there is no obvious sign anything is wrong.
Why This Matters for Your Business
You might be thinking: we are not software developers, we do not install npm packages. That is true. But you almost certainly rely on people who do.
Your website developer. Most modern websites, including those built on platforms like Next.js, are built using npm packages. If your developer ran a build or update between March 30 and March 31, their machine may have been compromised. A compromised developer machine can mean access to your website hosting credentials, your DNS settings, your database, and your customer data.
Your IT provider or MSP. Managed service providers frequently use developer tools and automation scripts internally. If their build environment pulled down the poisoned axios versions, their systems could be compromised. As we have written before, your security is only as strong as the vendors you trust.
Your SaaS applications. Any cloud application that runs JavaScript on the server side and updated its dependencies during the exposure window may have been affected. This includes internal tools, CRMs, and project management platforms built on Node.js.
The LexisNexis breach earlier this year followed a similar logic. A trusted third-party vendor was compromised and downstream clients paid the price. Axios is a larger-scale version of the same pattern.
What You Should Do This Week
You do not need to understand npm to take action. Here is what Cubit Cyber recommends for Australian SMEs.
1. Ask Your Developer and IT Provider Directly
Contact your website developer, your IT provider, and any software development firms you use. Ask them a direct question: "Were any of your systems used to build or update software between March 30 and April 1, 2026? If so, have you checked for compromised axios versions and rotated your credentials?"
A good technology partner will take this question seriously and give you a straight answer. Defensiveness or vagueness is a red flag. For a checklist of what to ask your IT provider, read our vendor supply chain audit guide.
2. Treat Exposed Credentials as Compromised
If any of your vendors confirm they were affected, treat every credential they had access to as potentially stolen. This means:
- Rotating API keys and passwords for any system they could access
- Reviewing access logs for unusual activity in the days following March 30
- Revoking and reissuing any tokens used for cloud platforms, hosting environments, or databases
If you have a password manager in use across your business, this process is much faster. If you do not, read our guide on why password spreadsheets are a liability.
3. Check Your Own Developer Tooling
If your business has any internal developers or technical staff who run Node.js projects, check whether axios versions 1.14.1 or 0.30.4 are present in any project dependency files. The safe versions are 1.14.0 and 0.30.3 or earlier. If the compromised versions were installed, treat the machine as potentially compromised and rotate all credentials accessible from that device.
4. Review Your Vendor Access Controls
This incident is a timely reminder to audit which of your vendors and IT providers have access to your critical systems. Specifically:
- Which vendors have admin access to your website or hosting environment?
- Which have credentials to your cloud storage, email platform, or CRM?
- When did you last review or rotate those credentials?
The goal is not to distrust your vendors. It is to limit the blast radius if one of them is ever compromised through no fault of their own.
The Broader Lesson for Australian SMEs
Supply chain attacks are increasingly the preferred method for sophisticated threat actors. Rather than attempting to compromise each target individually, attackers compromise a widely trusted tool or service and let the infection propagate through normal business activity. From the attacker's perspective, it is extraordinarily efficient.
The Australian Cyber Security Centre has flagged state-sponsored supply chain attacks as a growing priority threat. The axios incident, attributed to a North Korean group, is consistent with the pattern we saw earlier this year with INC ransomware targeting Australian professional services firms.
You cannot audit every piece of software that every vendor uses. But you can reduce your exposure by:
- Keeping vendor access scoped to exactly what they need
- Rotating credentials regularly, not just after incidents
- Asking your IT providers what controls they have in place to detect compromised dependencies in their own tooling
Small businesses do not need to solve supply chain security at a national level. They need to make it harder for a vendor compromise to become their compromise.
If you want to understand how exposed your business is through your current vendor relationships, a Cubit Cyber security assessment maps exactly that. We identify which third parties have access to your critical systems and help you put the right controls in place before an incident forces your hand.
Get in touch with our team to discuss a security assessment for your business.