It Took 24 Hours For Our First Article To Come True.

#security #webdev #opensource #cybersecurity

Yesterday we published an article arguing that every business needs to treat security as a continuous practice — not a checkbox. We talked about running penetration tests on day one, scanning your own infrastructure before someone else does, and preparing for a world where AI makes attacks faster and smarter.

We did not expect the proof to arrive within 24 hours.

The Axios Attack

On March 31st, a precision-guided remote access Trojan was discovered inside Axios — a JavaScript HTTP library with over 100 million weekly downloads on npm. This is not some obscure package buried deep in a dependency tree. Axios is one of the most widely-used libraries in the JavaScript ecosystem.

The attack was sophisticated — and it was not the work of amateurs. Google’s Threat Intelligence Group has attributed it to UNC1069, a financially motivated North Korea-nexus threat actor that has been active since at least 2018. The attacker compromised the npm account of Axios’s lead maintainer, changed the registered email to a ProtonMail address they controlled, published two malicious versions within minutes of each other, and slipped a rogue dependency into the release. On install, a post-install script silently contacted a command-and-control server, downloaded a cross-platform RAT tailored to the target operating system — Windows, macOS, and Linux each got a native implementation — established persistent remote access, stole credentials, and then deleted its own traces. Running npm audit after infection raised zero flags.

If your CI/CD pipeline installed either of the compromised versions, the attacker potentially had access to your AWS credentials, API keys, environment variables, and anything else on the machine.

Fireship covered this in detail. John Hammond also covered the attack independently. Elastic Security Labs, Google Threat Intelligence, Snyk, and Sophos have all published technical analyses. This is not speculation — it happened, it affected production systems, and the malicious versions were live on npm for approximately two hours before being pulled.

[

▶

](https://www.youtube.com/watch?v=o7NYXvYohYk)
Fireship’s breakdown of the Axios supply chain attack — how one compromised npm account became a weapon against 100 million projects. Watch on YouTube →

Why This Matters More Than You Think

Here is the uncomfortable truth: almost every modern web application is built on a tower of third-party dependencies. A typical React project pulls in hundreds of packages. Each package has its own maintainers, its own security practices, and its own attack surface.

You are not just trusting the code you write. You are trusting every maintainer, every contributor, every CI pipeline, and every npm account in your entire dependency graph. One compromised account — one — and a library that 100 million projects depend on becomes a weapon.

This is not a new risk. Supply chain attacks have been escalating for years. But the Axios attack represents a step change in sophistication. The self-cleaning payload, the OS-aware targeting with native implementations for three platforms, the credential exfiltration — this is not a script kiddie dropping a crypto miner. This is a state-linked operation attributed to a North Korean threat group with an eight-year track record.

And this happened before Mythos-class AI models are widely available. When those models arrive, the reconnaissance, the social engineering, the code analysis needed to find injection points — all of it gets faster.

What We Do Differently

At DESIGN-R.AI, we made an architectural decision early on: minimise third-party dependencies. Not because we enjoy reinventing wheels — because every dependency is an attack surface you do not control.

Our portal runs on vanilla JavaScript. No React. No Angular. No Vue. No bundler. No transpiler. The entire front-end is HTML, CSS, and JS that we wrote, that we audit, and that we control.

Our back-end runs on Node.js with Express — and we actively work to keep the dependency count low. We do not install a package for something the platform provides natively. fetch is built into Node.js now. We use it.

This is not anti-library ideology. It is a security posture. Every package you add is a package you need to trust, monitor, update, and defend. When Axios gets compromised, projects using native fetch are unaffected. When a CSS framework gets a supply chain injection, projects using hand-written CSS are unaffected. When a build tool gets backdoored, projects with no build step are unaffected.

The fewer dependencies you have, the smaller your blast radius.

The Day-One Protocol — Updated

In our previous article, we outlined a four-hour protocol for testing your infrastructure when a new capability jump arrives. The Axios attack adds a fifth step:

Hour 5: Audit your dependency graph. Run npm audit. Check your lock files. Review what actually gets installed when you run npm install. Look for packages you do not recognise. Check that your critical dependencies have not changed maintainers recently. Consider whether each dependency is truly necessary — or whether the platform provides the same capability natively.

Better yet, do this before an incident forces you to.

The Real Lesson

The Axios attack is not just about Axios. It is about the structural vulnerability of building on code you do not control. It is about the difference between convenience and security. It is about understanding that when you npm install a package, you are making a trust decision about every person who has ever had — or will ever have — publish access to that package and its dependencies.

You can mitigate this. You can pin versions. You can use lock files. You can run security audits. You can monitor for unusual releases. All of those are good practices.

Or you can write the code yourself, own every line, and reduce your attack surface to zero third-party dependencies. That is what we do. It takes longer. It requires more skill. And when the next Axios happens — because there will be a next one — it will not be our problem.

—

Key Facts: Axios npm Supply Chain Attack (March 2026)

What happened: Two malicious versions of the Axios npm package (100M+ weekly downloads) were published after the lead maintainer’s npm account was compromised. The account email was changed to an attacker-controlled ProtonMail address.
Attack vector: A rogue dependency (plain-crypto-js@4.2.1) was added to the release. Its post-install script contacted a command-and-control server, downloaded a cross-platform RAT with native implementations for Windows, macOS, and Linux, exfiltrated credentials (AWS keys, API tokens, environment variables), then deleted its own traces.
Timeline: March 30, 2026 23:59 UTC — malicious dependency published. March 31, 00:21 UTC — compromised axios@1.14.1 published. March 31, 01:00 UTC — compromised axios@0.30.4 published. March 31, 03:29 UTC — malicious versions removed. Total exposure window: approximately 2 hours.
Attribution: Google Threat Intelligence Group attributes this to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018, based on the WAVESHAPER.V2 malware family.
Detection evasion: After installation, npm audit showed no warnings. The RAT dropper removed the post-install script, the rogue dependency’s package.json, and its own binary — leaving a clean-looking node_modules directory.
Impact: Any developer or CI/CD pipeline that installed the compromised versions had full system compromise — credential theft, persistent remote access, and potential lateral movement.
Confirmed by: Google Threat Intelligence, Elastic Security Labs, Snyk, Sophos, Step Security, Fireship, John Hammond
Safe versions: axios@1.14.0 (last legitimate 1.x with SLSA provenance), axios@0.30.3 (last legitimate 0.30.x)
Remediation: Affected systems should be treated as fully compromised and rebuilt from a known-good state. Roll all API keys, tokens, and credentials immediately.

Frequently Asked Questions

Q: How do I check if I’m affected by the Axios supply chain attack?

A: Check your package.json and package-lock.json for the compromised Axios versions. Search your node_modules for a package called plain-crypto-js. On Linux/Mac, check for the RAT binary using the detection commands published by Step Security.

Q: Is Axios safe to use now?

A: The compromised versions have been removed from npm. However, this attack demonstrates the fundamental risk of depending on third-party packages — any maintainer account compromise can turn a trusted package into a weapon. Consider whether native fetch (available in all modern JavaScript runtimes) meets your needs.

Q: What is a supply chain attack?

A: A supply chain attack targets software dependencies rather than the application itself. Instead of finding a vulnerability in your code, the attacker compromises a library your code depends on. Because modern applications often have hundreds of dependencies, the attack surface is vast.

Q: How can businesses protect against npm supply chain attacks?

A: Pin dependency versions, use lock files, run regular npm audit checks, monitor for maintainer changes on critical packages, minimise your dependency count, prefer native platform APIs over third-party wrappers, and consider using a private npm registry that screens packages before making them available.

Q: What does DESIGN-R.AI do differently to avoid supply chain attacks?

A: DESIGN-R.AI uses a minimal-dependency architecture. The portal front-end runs on vanilla JavaScript with no framework, no bundler, and no transpiler. The back-end uses Node.js with Express and actively avoids installing packages when the platform provides equivalent functionality natively. This reduces the attack surface to code the team writes, audits, and controls directly.