The Axios Attack Is a Vibe Coding Wake-Up Call

Yesterday, one of the most widely used libraries in JavaScript was compromised.

Axios: the HTTP client sitting inside virtually every React, Next.js, and Node project had two versions pushed to npm via a hijacked maintainer account. Both contained a hidden Remote Access Trojan. Anyone whose CI/CD pipeline ran npm install during the two-hour window those versions were live had their build environment silently compromised, their credentials exfiltrated, and all traces of the attack erased before they noticed anything.

100 million weekly downloads. Two hours. No trace left behind.

Here's the part that isn't being talked about: if you built your product with Lovable, Bolt, or Claude Code then you almost certainly have Axios in your stack. Not because you chose it. Because the AI did. And you accepted all changes without reviewing package.json, without running npm audit, without ever seeing the word "Axios" in the process.

That's not a criticism. That's exactly how vibe coding is supposed to work.

And that's exactly why this attack hits vibe-coded products harder than anything else.

What actually happened

On March 31, 2026, attackers compromised the npm account of the primary Axios maintainer and published two poisoned versions of the library: axios@1.14.1 and axios@0.30.4.

Axios is the HTTP client used in most of the JavaScript project. It handles the requests your app makes to external APIs like payment gateways, databases, third-party services. Over 100 million packages download it weekly. 175,000 npm projects list it as a direct dependency. If you've built anything with React, Next.js, Node, or any modern JavaScript stack in the last five years, Axios is almost certainly in your codebase.

The attackers didn't touch Axios's source code. They simply injected a new dependency: plain-crypto-js@4.2.1 into the package.json of both compromised versions. This package had been staged 18 hours earlier, with a clean version published first to build a brief history on the registry before the malicious version went live.

When any developer or CI/CD pipeline ran npm install during the two-hour window the versions were live, npm resolved the dependency tree, pulled plain-crypto-js@4.2.1, and automatically executed its postinstall hook. That single script setup.js was a cross-platform RAT dropper. It contacted a command-and-control server, downloaded platform-specific payloads for macOS, Windows, or Linux, and then systematically erased all evidence of itself.

The malware dropper cleaned up completely. The postinstall script was deleted. The package.json was replaced with a clean version. Any inspection of node_modules/plain-crypto-js after infection would show a completely innocent package. Even npm audit would show nothing.

The only indicator of compromise: the presence of the plain-crypto-js folder in node_modules at all. Axios has exactly three legitimate dependencies. plain-crypto-js is not one of them.

The compromised versions were removed from npm by 03:29 UTC, a roughly two-hour window. Security researchers attributed the attack to North Korean state actors based on the tactics and infrastructure involved. This was not opportunistic. Three separate payloads were pre-built for three operating systems. Both release branches were hit within 39 minutes of each other. Every trace was designed to self-destruct.

Why vibe-coded products are the most exposed

Every security post about this attack will cover the technical details. What nobody else is saying: this attack is uniquely dangerous for products built with AI coding tools.

Here's why.

When you write code manually, you make conscious dependency decisions. You type npm install axios. You see the version that installs. You review package.json before committing. You know what's in your node_modules because you put it there.

When AI generates your code, none of that happens. The AI selects dependencies based on what it was trained on, what's most common in the ecosystem, what solves the problem fastest. Axios is an obvious choice for almost any HTTP operation, so it gets added automatically, silently, as part of a generated project. You accept all changes. The code works. You move on.

This means vibe-coded projects tend to have:

Unreviewed dependency trees. The founder never looked at package.json. They have no idea Axios is in there, let alone which version.

Unpinned versions. AI-generated projects often use ^ in version specifiers "axios": "^1.14.0", which means npm install will automatically pull the latest compatible version. When 1.14.1 was the latest, that's what installed.

No npm audit in the pipeline. Security scanning isn't part of the vibe coding workflow. You describe, generate, deploy. The security review that used to happen between "written" and "shipped" gets skipped entirely.

CI/CD pipelines that run npm install on every build. Every deployment, every preview, every branch, fresh install. Any of those runs during the two-hour window would have executed the dropper.

The 45% of AI-generated code that contains security vulnerabilities, a figure documented by Veracode doesn't account for supply chain attacks at all. That number covers flaws in the generated code itself. This attack required no flaw in any generated code. It exploited the implicit trust that AI tools extend to the packages they include.

What was actually at risk

If your CI/CD pipeline installed axios@1.14.1 or axios@0.30.4 between 00:21 UTC and 03:29 UTC on March 31, assume your build environment is compromised. Specifically:

• npm tokens: any token used to authenticate with npm during the build
• Cloud provider credentials: AWS keys, GCP service accounts, Vercel tokens, anything in environment variables
• SSH keys present on the build machine
• API keys in your .env file or injected as CI/CD secrets
• Database credentials: Supabase keys, Postgres connection strings, anything your app needs at runtime

The RAT established a persistent connection to a command-and-control server. What was exfiltrated during the window it was active is unknown. Assume everything.

Most vibe-coded founders don't have a complete inventory of what secrets their CI/CD pipeline holds. That's the compounding problem as you can't rotate credentials you don't know you have.

What to do right now

If you think you may have been affected:

Check your Axios version immediately with below command:

npm list axios

If you see 1.14.1 or 0.30.4, assume compromise. Then:

1. Downgrade immediately to axios@1.14.0 or axios@0.30.3
2. Remove the malicious package: rm -rf node_modules/plain-crypto-js
3. Reinstall cleanly: npm install --ignore-scripts
4. Rotate everything — npm tokens, cloud provider keys, API keys, SSH keys, database credentials. All of them. Do not try to determine what was accessed. Assume all of it was.
5. Audit your CI/CD logs for any runs during the 00:21–03:29 UTC window on March 31
6. Block the C2 domain sfrclak[.]com at your firewall or DNS level

For all projects going forward whether they are vibe-coded or not:

Pin your dependency versions exactly. Instead of "axios": "^1.14.0", use "axios": "1.14.0". Exact versions mean npm install never silently pulls a newer version. This is the single highest-leverage change for any project.

Add --ignore-scripts to your CI pipeline. This prevents postinstall hooks from running automatically during install. Most legitimate packages don't need them. Malicious ones almost always do.

Run Snyk or Socket on every build. Both flagged this attack within hours. Socket in particular detected the anomaly with Axios's three legitimate dependencies suddenly becoming four almost immediately. Free tiers exist. There's no excuse.

Know what's in your dependency tree. Run npm list --depth=0 and look at it. If you're using a vibe coding tool, check the package.json the AI generated before you deploy. This takes two minutes.

The pattern that isn't going away

Axios is this week. Before it, Chalk and Debug were compromised in September 2025. Before that, a worm in December 2025 stole 400,000 developer secrets via infected npm packages. The same playbook, compromise a maintainer account, inject a malicious dependency, let the ecosystem's trust do the rest.

The reason this pattern keeps working is that the JavaScript ecosystem runs on implicit trust. When you run npm install, you trust that every package in your dependency tree was published by who it claims to be, contains what it claims to contain, and does only what it claims to do. That trust is being systematically exploited.

Vibe coding accelerates the pace at which that trust gets extended. When AI generates your entire dependency tree in a single prompt, you're trusting dozens of packages you never consciously chose, across multiple layers of transitive dependencies, all at once.

The answer isn't to stop using AI tools. The answer is to build the security layer that AI tools currently skip.

That means pinned versions, --ignore-scripts, dependency scanning in CI, and at minimum a ten-minute review of package.json before every deployment.

It's not much. But it's the difference between "my app shipped fast" and "my credentials were rotated at 3am because a nation-state exploited a library I didn't know I was using."

Where BuildOrbit fits

When we build products for founders, dependency security isn't an afterthought. Every project ships with pinned versions, npm audit in the pipeline, and a dependency review as part of the build process.

If you've vibe-coded something that's either in production or approaching launch and you want a security review of the dependency tree and build pipeline before an incident forces, one a conversation worth having now.

rahul@habitize.app