The Axios NPM Attack: What Every Business Needs to Know About Supply Chain Security

If your business runs a website, a web application, or pretty much any modern software — there's a good chance a package called Axios is somewhere in the stack. As of this morning, that's a problem.

On March 31, 2026, attackers linked to North Korea compromised the Axios npm package — one of the most widely used open-source libraries on the internet, with roughly 100 million downloads per week and over 400 million monthly. They published backdoored versions that installed remote access trojans on any system that pulled the update. The exposure window lasted approximately three hours before the malicious versions were pulled.

Three hours doesn't sound like much. But within 89 seconds of the malicious version going live, security firm Huntress observed the first infected system. Sophos detected related activity in customer telemetry by 00:45 UTC. Within that three-hour window, Huntress confirmed at least 135 compromised endpoints across their customer base alone — spanning Windows, macOS, and Linux.

This is a big deal. Here's what you need to know.

What is Axios, and why should you care?

Axios is a JavaScript library that helps applications make HTTP requests — essentially, it's the plumbing that lets your app talk to APIs, fetch data, and communicate with servers. It's used by an enormous number of websites and applications worldwide.

If you're not a developer, think of it like this: Axios is a common building block that thousands of software projects rely on. When that building block gets poisoned, every project using it is at risk.

Your development team almost certainly knows what Axios is. They may already be using it. That's what makes supply chain attacks so effective — they don't target your software directly. They target the tools your software depends on.

What happened: A timeline

This wasn't a smash-and-grab. It was a carefully planned operation with pre-staged infrastructure.

March 30, 23:59 UTC — The attackers published a fake package called plain-crypto-js@4.2.1 to the npm registry. This package had never existed before. It sat there quietly, waiting — a pre-staged weapon.

March 31, 00:05 UTC — Security researchers at Socket flagged the malicious package within six minutes of publication. But the real attack hadn't started yet.

March 31, 00:21 UTC — The attackers used compromised credentials belonging to Jason Saayman, the lead Axios maintainer, to publish axios@1.14.1 as the "latest" version. This version included the fake plain-crypto-js as a dependency.

March 31, 00:23 UTC — Huntress observed the first infection — just 89 seconds after publication.

March 31, ~00:45 UTC — Sophos detected attack-related activity in their customer telemetry.

March 31, ~01:00 UTC — A second malicious version, axios@0.30.4, was published targeting the legacy release line — catching organizations running older versions too.

March 31, 03:29 UTC — npm removed the malicious packages from the registry, closing the exposure window at approximately three hours and eight minutes.

How the attack worked

The technical execution was disturbingly sophisticated — and designed to cover its tracks.

Rather than modifying the Axios source code directly (which would have been easier to spot in code review), the attackers added a single line to package.json: a new dependency on plain-crypto-js@4.2.1. When a developer ran npm install and pulled the compromised Axios version, npm automatically installed this fake dependency too. No user interaction required.

The fake package included a "postinstall" script — a mechanism npm supports for running setup tasks after installation. This script executed a file called setup.js, which used two layers of obfuscation: reversed Base64 encoding with modified padding, plus XOR encryption. Once decoded, the dropper fingerprinted the host operating system and downloaded a platform-specific payload from the attacker's command-and-control server.

On Windows: The malware used a VBScript downloader that copied PowerShell to C:\ProgramData\wt.exe — renaming it to evade security tools that monitor PowerShell activity. It then launched a hidden remote access trojan with execution policy bypass, along with a batch script launcher at C:\ProgramData\system.bat.

On macOS: A binary was downloaded to /Library/Caches/com.apple.act.mond, disguised as a legitimate Apple daemon. The RAT beaconed to the command-and-control server every 60 seconds and included Gatekeeper bypass capabilities — meaning it could run even on systems with Apple's standard security protections enabled.

On Linux: A Python-based payload was dropped to /tmp/ld.py and launched as a background process using nohup, ensuring it survived even if the terminal session ended.

All three payloads gave attackers the ability to execute arbitrary commands, steal credentials, exfiltrate data, enumerate directories, and maintain persistent access across reboots.

And here's the part that makes forensics especially difficult: after infection, the dropper deleted itself, removed the modified package.json, and replaced it with a clean copy. The attack was designed to leave no obvious trace of how it got in.

Who was behind it?

Google's Threat Intelligence Group attributed the attack to UNC1069, a North Korean threat actor also known as BlueNoroff. This group has a well-documented track record of targeting cryptocurrency exchanges, software developers, financial institutions, and venture capital firms.

The attribution is backed by multiple technical links. The macOS malware used an internal project name — "macWebT" — that directly connects to BlueNoroff's documented "webT" module, previously identified by Elastic and Jamf researchers. The command-and-control infrastructure overlapped with domains previously tied to North Korean operations by Volexity and other threat intelligence firms.

Two attacker-controlled email addresses were associated with the operation: nrwise@proton[.]me and ifstap@proton[.]me.

This is consistent with a broader pattern. North Korean cyber operations are increasingly focused on financially motivated attacks, and supply chain compromises give them extraordinary reach from a single point of access.

How was the maintainer's account compromised?

The attackers gained access to the Axios maintainer's npm credentials. Once inside, they changed the account's associated email address to a Proton Mail account they controlled, effectively locking out the legitimate owner.

But there's a deeper issue here. The Axios project's publishing workflow passed both a long-lived npm access token and OpenID Connect (OIDC) credentials as environment variables. npm prioritizes token-based authentication over OIDC — which means the OIDC security protections that were supposed to be in place were effectively bypassed.

In other words: the project had implemented a more secure authentication method, but a configuration weakness allowed the attacker to sidestep it entirely.

How do you know if you're affected?

If your organization builds or deploys JavaScript applications, you need to check. Here's what to look for.

Check your lock files. This is the fastest way. Have your development team run:

grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

Check for the malicious dependency directly:

npm ls plain-crypto-js
find node_modules -name "plain-crypto-js" -type d

Check your CI/CD systems. Automated build and deployment systems that ran during the exposure window (00:21 to 03:29 UTC on March 31, 2026) may have pulled the compromised versions. Overnight builds were particularly at risk.

Check developer machines. Any developer who ran npm install during that window could have an infected workstation.

Check for indicators of compromise on endpoints:

• Windows: Look for C:\ProgramData\wt.exe or C:\ProgramData\system.bat
• macOS: Look for /Library/Caches/com.apple.act.mond
• Linux: Look for /tmp/ld.py
• Network: Check for outbound connections to sfrclak[.]com, callnrwise[.]com, or 142.11.206.73 on port 8000

If you find any of these, assume full compromise of that system.

What to do right now

If you've confirmed exposure — or even suspect it — here's your action plan:

Immediate (today)

1. Identify affected systems. Scan all projects, build servers, and developer machines for the compromised versions and indicators of compromise listed above.
2. Isolate compromised systems. Remove affected machines from your network immediately.
3. Update Axios. Pin to version 1.14.0 or 0.30.3 (the last known safe versions) across all projects.
4. Block the C2 infrastructure. Add sfrclak[.]com, callnrwise[.]com, and 142.11.206.73 to your network blocklists.
5. Rotate all credentials. Any secrets, API keys, SSH keys, database passwords, cloud credentials, or tokens that existed on a compromised system should be considered stolen. Rotate everything.

This week

6. Rebuild affected systems from clean snapshots. Don't just remove the malware — rebuild from scratch. The RAT established persistence mechanisms designed to survive cleanup attempts. Attempting to remediate in place is not sufficient.
7. Investigate lateral movement. Check logs for unusual activity originating from compromised systems. The attackers had arbitrary command execution — they may have moved to other systems on your network.
8. Audit access logs. Review authentication logs for any accounts that may have been accessed from compromised endpoints.
9. Notify stakeholders. If customer data may have been accessible from compromised systems, your incident response plan should include notification procedures.

Going forward: Hardening your dependency supply chain

10. Pin exact dependency versions. Stop using caret ranges (^1.14.0) that automatically pull new minor versions. Lock to specific, verified versions.
11. Use npm ci instead of npm install in CI pipelines. This enforces strict lockfile compliance — if the lockfile doesn't match package.json, the build fails rather than silently resolving to a new version.
12. Run npm ci --ignore-scripts in build environments. This prevents postinstall hooks from executing during builds — which is exactly the mechanism this attack exploited.
13. Commit your lock files. Ensure package-lock.json or yarn.lock is committed to your repository and used in all builds. This is your defense against phantom dependency attacks.
14. Enable npm audit in your CI/CD pipeline. Automated security scanning catches known vulnerabilities before they reach production.
15. Review npm account security. Any npm accounts used for publishing should have two-factor authentication enabled — and verify that it's actually being enforced, not just available.
16. Monitor outbound network activity from build systems. Build servers shouldn't be making unexpected connections to unknown domains. If they are, you want to know about it.
17. Consider a dependency security tool. Solutions like Socket, Snyk, or Endor Labs can flag suspicious packages, detect typosquatting, and alert on dependency changes before they reach your systems.

The bigger picture: This is a pattern, not an anomaly

This isn't the first supply chain attack on a package registry, and it won't be the last. The Axios compromise follows a growing pattern of registry-targeting attacks — including incidents affecting ESLint, the Shai-Hulud campaign, and LiteLLM.

What distinguishes the Axios attack is the combination of scale and operational sophistication. Pre-staged infrastructure. Double-layer obfuscation. Platform-specific RATs tailored to each operating system. Anti-forensic cleanup. This wasn't an opportunistic compromise — it was a professional operation by a state-sponsored threat actor.

The model is too effective for threat actors to abandon. Modern software development relies on thousands of open-source packages. A typical web application might have hundreds of direct dependencies and thousands of transitive ones — packages that your packages depend on. Each one is a potential entry point.

And most of these packages are maintained by individuals or small teams, often as unpaid volunteer work. One compromised account, one moment of credential reuse, and an attacker has access to software running on millions of systems.

What this means for your business

If you're a business leader who doesn't live in the world of npm packages and dependency management, here's the takeaway:

Your software has a supply chain. Just like physical products depend on raw materials from suppliers, your software depends on code written by people you've never met. That supply chain needs to be managed with the same rigor you'd apply to any critical vendor relationship.

Your development team needs security practices around dependencies. Pinning versions, auditing dependencies, scanning for vulnerabilities, disabling automatic script execution in builds — these should be standard parts of your development process, not nice-to-haves.

Incident response planning should include supply chain scenarios. If a critical dependency is compromised, does your team know what to do? How quickly can they identify affected systems? Do they have a playbook? The three-hour window in this attack left very little time for deliberation.

This is a board-level conversation. Supply chain attacks can affect any company that builds or uses software — which is every company. The risk should be understood and managed at the leadership level, not left entirely to developers.

How we think about this at Entvas

When we build software for clients, dependency security is part of our standard practice — not a bolt-on afterthought. That means pinned versions, lockfile enforcement, automated vulnerability scanning, disabled postinstall scripts in CI environments, regular dependency audits, and build processes designed to catch exactly this kind of compromise.

We also help clients establish the practices and tooling that make supply chain attacks manageable: from CI/CD pipeline security to dependency management policies to incident response planning.

The Axios incident is a stark reminder that the code you write is only part of the security equation. The code you depend on matters just as much — and today, it matters urgently.

If you're not sure how exposed your organization is — or whether your development practices would have caught this — we're happy to take a look. Better to find out now than during the next incident.

Entvas Editorial Team

Helping businesses make informed decisions