The Axios npm Attack: What Calgary Businesses Running Node.js Need to Do This Week

The Axios npm Attack: What Calgary Businesses Running Node.js Need to Do This Week

On the evening of March 30, 2026, one of the most widely depended-on packages in the JavaScript ecosystem was quietly replaced with a backdoored version on the npm registry. Within about three hours, North Korean state-sponsored operators had been given a free pass into the install pipeline of nearly every Node.js project on the planet - including the ones running behind Canadian bank portals, e-commerce stores, customer dashboards, and internal business tools.

The package was axios. It pulls roughly 100 million downloads a week. If you run a business in Calgary that has a web app, a customer portal, a booking system, or any modern website built on Next.js, Nuxt, Express or NestJS, there is a very high chance axios is sitting somewhere in your dependency tree right now - whether your developers chose it directly or one of your other packages dragged it in.

This post explains what happened, why it matters specifically for SMB-sized businesses in Calgary, and the exact, non-negotiable steps your development team should be running this week. We also cover what to ask any outside vendor or freelancer who writes code on your behalf, because the humans who control your packages are now the soft targets - not the servers.

What Actually Happened

Between the late hours of March 30 and the early hours of March 31, 2026 (all times in UTC), two booby-trapped versions of axios were published to the npm registry from the account of the package's lead maintainer, Jason Saayman:

• axios@1.14.1, tagged as the default latest release
• axios@0.30.4, tagged as the legacy release

Both distribution tags pointed at poisoned code. That meant that during the three-hour window the packages were live, any fresh npm install, any CI/CD build, and any Dockerfile that started with RUN npm install was at real risk of pulling the compromised version. Elastic Security Labs, which detected the attack via automated monitoring, filed a GitHub Security Advisory at 01:50 UTC on March 31 and the npm registry pulled the bad versions shortly after. The safe, clean versions are axios@1.14.0 and axios@0.30.3.

The malicious code itself was not sitting inside axios. It was staged through a typosquatted package called plain-crypto-js@4.2.1 that the attackers added as a runtime dependency inside the booby-trapped axios releases. That dependency had been published 18 hours earlier as a clean decoy (4.2.0) to build a normal-looking release history, and then silently updated with the malicious version right before the axios releases dropped. Elastic's analysts described the timing as "precision" - this was not opportunistic.

Here is the compressed timeline Elastic and StepSecurity reconstructed:

• Feb 18 - the legitimate axios@0.30.3 is published using GitHub Actions OIDC with SLSA provenance.
• Mar 27, 19:01 UTC - the legitimate axios@1.14.0 is published the same way.
• Mar 30, 05:57 UTC - a clean decoy plain-crypto-js@4.2.0 is published.
• Mar 30, 23:59 UTC - the malicious plain-crypto-js@4.2.1 is pushed with a postinstall hook.
• Mar 31, 00:21 UTC - axios@1.14.1 is published from the compromised maintainer account - with no OIDC, no SLSA attestation, and no matching GitHub commit or tag.
• Mar 31, 01:00 UTC - axios@0.30.4 is published 39 minutes later.
• Mar 31, ~03:15 UTC - npm pulls both malicious axios versions.
• Mar 31, 04:26 UTC - npm replaces the malicious plain-crypto-js with a security stub.

Once installed, the package used npm's postinstall hook to run a short obfuscated JavaScript dropper. That dropper fingerprinted the host, picked a platform-specific payload, and reached out to a command-and-control server at sfrclak[.]com:8000. On macOS it planted a backdoor disguised as an Apple system daemon at /Library/Caches/com.apple.act.mond. On Windows it wrote a fake wt.exe into %PROGRAMDATA% to masquerade as Windows Terminal and set up registry-key persistence. On Linux it dropped a Python-based implant in /tmp. Then it deleted its own traces from the package directory.

The final-stage implant is a cross-platform Remote Access Trojan with PowerShell, C++ and Python variants. It is a full backdoor: process enumeration, file listing, reflective .NET loading on Windows, remote command execution, and a 60-second beacon cadence. In one of the few comic details in this story, every variant of the RAT hardcoded the same absurdly out-of-date HTTP User-Agent - Internet Explorer 8 on Windows XP - making the traffic trivially detectable on any modern network. StepSecurity's Harden-Runner tool caught the first C2 callback from an infected CI job exactly 1.1 seconds after npm install started.

How a Package With 100 Million Weekly Downloads Gets Hijacked

Here is the part that matters for every business owner reading this: the attackers did not break into npm, they did not exploit a CI pipeline bug, and they did not find a zero-day in axios itself. They broke a human.

In his personal post-mortem on GitHub (issue #10636), Jason Saayman described how the attackers spent weeks building trust with him while pretending to be the founder of a real, well-known company. They cloned the founder's likeness, built a fake Slack workspace with realistic channels, populated it with LinkedIn posts and profiles from invented teammates, and eventually booked a Microsoft Teams meeting under the pretext of a business discussion. During the call a fake error message told him something on his system was out of date and prompted him to install a "fix." The "fix" was malware that stole his npm credentials.

That malware is part of a family called WAVESHAPER, which Mandiant attributes to UNC1069 - the threat cluster Microsoft tracks as Sapphire Sleet and other vendors track as BlueNoroff. It is a North Korean state-sponsored group, and it has been running the same playbook against other high-value open-source maintainers at the same time. Socket's investigation identified multiple simultaneous targets including Jordan Harband (ECMAScript polyfills), John-David Dalton (Lodash), Matteo Collina (Fastify, Pino, Undici), Scott Motte (dotenv), and Pelle Wessman (Mocha). Some resisted. Saayman's account was the one that got through.

Why go after open-source maintainers instead of enterprises directly? Because one compromised axios publish reaches every Node.js project in the world at once. It is the highest-leverage phishing target you could possibly imagine. Security researcher Taylor Monahan summed it up bluntly after the disclosure: "They social engineer them and take over their accounts and target the next round of people. This evolution to targeting OSS maintainers is a bit concerning in my opinion."

And yes, even very senior technical people can get caught. Andrej Karpathy, the AI researcher and the person who coined the term "vibe coding," publicly admitted after the disclosure that his own system had pulled axios@1.14.1 before npm yanked it. If Karpathy can get hit, your e-commerce store's build server can get hit.

Why This Matters for a Calgary Business That Is "Not Even Technical"

A common reaction we get from non-technical business owners is "we do not write JavaScript, so this does not apply to us." Unfortunately, it almost certainly does.

If any of the following is true of your business, axios is in your stack:

• You have a website built on Next.js, Nuxt, Remix or Gatsby - any modern JavaScript framework
• You have a customer portal, booking system or admin dashboard that was built in the last five years
• You run a Shopify, BigCommerce or WooCommerce store that uses custom plugins or headless front-ends
• Your mobile app was built in React Native or Expo
• You use any internal tool your developers built - even a simple CSV uploader
• You pay a Calgary web developer or a remote agency to maintain any of the above

In every one of those cases, axios is likely pulled in somewhere - either directly or as a transitive dependency. The Canadian Centre for Cyber Security's National Cyber Threat Assessment for 2025-26 explicitly warned Canadian small and mid-sized businesses about state-sponsored supply-chain attacks, and this is a textbook example of exactly what they were warning about.

The real damage from a successful install is not that the attackers now have your website code. It is that they can potentially reach the secrets your CI/CD system holds. Those secrets often include cloud credentials (AWS, Azure, GCP), database passwords, Stripe or payment processor keys, email API tokens, and code-signing certificates. An attacker who grabs those during a build can quietly pivot into the production side of your business without ever touching your front-end.

The Checklist Your Development Team Should Run This Week

If you have a developer in-house, a vendor, or a freelancer, forward this section to them. If you work with us at Rocky Soft, we have already run it on every client project we manage. Every line here is copy-and-runnable.

1. Check your lockfile for the compromised versions

grep -E '"axios".*"(1\.14\.1|0\.30\.4)"' package-lock.json
grep -E '"axios".*"(1\.14\.1|0\.30\.4)"' yarn.lock
grep -E '"axios".*"(1\.14\.1|0\.30\.4)"' pnpm-lock.yaml

If any of these return a match, treat the project as compromised until proven otherwise. The good versions are 1.14.0 and 0.30.3.

2. Check for the phantom dependency

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"
find ~ -type d -name "plain-crypto-js" -path "*/node_modules/*"

The plain-crypto-js package has no legitimate reason to be in your project. Its presence is a strong indicator that a bad install ran at some point.

3. Pin safe versions in your dependency manifest

Add an overrides block to your package.json so nothing in the tree can drift back onto the malicious versions:

{
  "overrides": {
    "axios": "1.14.0"
  }
}

4. Rotate every secret your CI/CD system touched

If any build ran between March 30 and March 31 and is now suspect, rotate all of the following from a clean machine:

• npm publish tokens
• GitHub/GitLab/Bitbucket personal access tokens and deploy keys
• AWS, Azure and GCP access keys
• Stripe, Twilio, SendGrid and any third-party API keys
• Database passwords
• SSH keys attached to any build agent
• Any signing certificates stored in CI

Assume leaked until proven otherwise.

5. Enforce a minimum release age on new package versions

This is the single highest-leverage preventive step for small teams. It tells your package manager: "do not pull any dependency version that is less than seven days old, no matter what." That seven-day cooling-off window is what would have protected every project that installed axios@1.14.1 during the attack window.

min-release-age=7d

npmMinimalAgeGate: "7d"

minimumReleaseAge: 10080

[install]
minimumReleaseAge = 604800

6. Disable postinstall scripts in CI

The attack relied entirely on npm running the postinstall hook inside plain-crypto-js. If your CI does not need install scripts - and most production builds do not - use --ignore-scripts (npm/Yarn) or the built-in safe defaults in Bun and pnpm. For your main CI pipeline:

npm ci --ignore-scripts

7. Block the known C2 infrastructure

If you run your own build servers, block outbound connections to the known command-and-control indicators at the network level:

• Domain: sfrclak.com
• IP: 142.11.206.73
• Port: 8000

Five Questions to Ask Your Dev Vendor

If you outsource development to an agency, freelancer, or contractor, forward them these questions. The answers tell you whether they take supply-chain security seriously or not.

1. Are any of our projects currently affected by the Axios March 31, 2026 compromise, and have you verified that in writing?
2. Do we enforce a minimum release-age policy on dependencies, and if so, how long?
3. Which CI secrets did our builds access between March 30 and March 31, and have those been rotated?
4. Do we run npm install with scripts enabled in production CI, and if so, why?
5. When a top-100 npm package ships a new major or minor version, what is our process for deciding whether to adopt it?

A dev partner who cannot answer those questions in plain English is a partner who is trading your reliability for their convenience. That is a legitimate signal to reconsider the relationship.

What This Means for the Bigger Picture

The Axios attack is not an isolated event. It is part of a pattern of state-sponsored targeting of open-source maintainers that accelerated throughout 2025 and into 2026. CISA issued an advisory about widespread npm compromise in September 2025. The Shai-Hulud npm worm compromised 796 packages and spread across 25,000 GitHub repositories in late 2025. GitHub announced a plan in 2025 to move the entire npm ecosystem to 2FA, seven-day-max tokens, and Trusted Publishers. The tooling is catching up, but the attackers are moving just as fast.

The lesson from this attack for Calgary SMBs is not "panic and rip out JavaScript." It is that modern software businesses depend on a supply chain you do not own, and that supply chain is now being actively targeted by nation-state actors. You do not need a dedicated security team to defend against that. You need a development partner who treats dependency hygiene, secret rotation and release-age policies as routine, not as things to do after an incident.

At Rocky Soft we treat these as part of our normal workflow on every project - not as optional extras, and not as things we mention only when asked. A seven-day cooling-off window on dependencies, --ignore-scripts in CI, automated lockfile scanning, and rotated secrets on a schedule are the boring, unglamorous controls that would have turned the Axios attack into a non-event for any business that had them in place.

At Rocky Soft, we build and maintain production-grade web and mobile applications for Calgary businesses - with supply-chain security, dependency hygiene, and CI/CD hardening built into every project from day one. If you want us to run the checklist above on your current codebase, or to take over maintenance of an app you are not sure is being looked after properly, get in touch.

Frequently Asked Questions

Is my business affected by the Axios npm attack?

If any software your business depends on is built on Node.js, Next.js, Nuxt, Remix, NestJS, Express, or React Native - or any modern JavaScript or TypeScript stack at all - there is a very high probability that axios is somewhere in your dependency tree. The actual question is whether your project installed the compromised version 1.14.1 or 0.30.4 during the roughly three-hour window on March 31, 2026. Your dev team can confirm this in under a minute by searching your lockfile for those version numbers.

I only had the bad version installed for a few minutes. Am I safe?

No. The malware fires on the postinstall hook and the first command-and-control callback happened about 1.1 seconds after npm install started in the CI runs that StepSecurity captured. If the install ran at all, assume the machine was contacted by attacker infrastructure and treat any secrets accessible to that machine as compromised. Rotate them.

What do the compromised Axios versions look like?

The malicious versions are axios@1.14.1 (tagged latest) and axios@0.30.4 (tagged legacy). The safe versions immediately before them are axios@1.14.0 and axios@0.30.3. The malicious versions were published without the usual OIDC attestation and had no matching GitHub commit or tag, which is how Elastic Security Labs initially flagged them.

Who was behind the Axios npm attack?

Google Threat Intelligence Group, Microsoft Threat Intelligence and Mandiant all attribute the attack to UNC1069, a North Korean state-sponsored threat cluster also known as Sapphire Sleet and BlueNoroff. The group social-engineered Axios maintainer Jason Saayman over several weeks using a fake company persona and a fake Microsoft Teams meeting, then used stolen credentials to publish the malicious versions directly from his npm account.

How do I prevent something like this from affecting us in the future?

The single most effective preventive control for small teams is enforcing a minimum release-age policy on npm dependencies - configuring your package manager to refuse any package version less than seven days old. Combined with running npm ci --ignore-scripts in CI, pinning dependency overrides, and rotating CI secrets on a schedule, this would have reduced the Axios attack to a non-event for anyone who had those defenses in place. Ask your dev team or vendor whether these controls are active on your projects.

Should we stop using open-source packages?

No - and that would be impossible in practice anyway. Every modern software product depends on hundreds of open-source packages, and replacing them with custom code would make your system less secure, not more. The answer is to depend on open source deliberately: pin versions, enforce release-age policies, audit dependency trees, and work with a development partner who treats supply-chain security as routine work rather than an afterthought.

Sources

• Groenewoud, R. et al. (2026). "Inside the Axios supply chain compromise: one RAT to rule them all." Elastic Security Labs. Read article
• Kurmi, A. (2026). "axios Compromised on npm: Malicious Versions Drop Remote Access Trojan." StepSecurity. Read article
• Lakshmanan, R. (2026). "UNC1069 Social Engineering of Axios Maintainer Led to npm Supply Chain Attack." The Hacker News. Read article
• Microsoft Threat Intelligence. (2026). "Mitigating the Axios npm supply chain compromise." Microsoft Security Blog. Read article
• Curtis, D. (2026). "Axios npm Package Compromised in Supply Chain Attack." InfoQ. Read article
• Saayman, J. (2026). "Security incident post-mortem - issue #10636." GitHub - axios/axios. Read post-mortem