Your Website Is One Compromised npm Package Away From Disaster

In March 2026, a North Korean hacking group published a backdoored version of axios to npm. Axios has 100 million weekly downloads. There's a decent chance it's in your website right now.

When I build a Next.js project for a client, I install maybe 5 to 10 packages I deliberately chose. But npm installs 300+ packages total. I've read the source code of approximately zero of them.

Nobody reads the packages. Nobody has time. And that's exactly what the attackers are counting on.

What Actually Happened With Axios

On March 30, 2026, at 23:59 UTC, someone hijacked the npm account of axios maintainer jasonsaayman. They changed the email to a Proton address and, 21 minutes later, published axios v 1.14.1 tagged as latest.

The attackers didn't break any existing code. They didn't add obvious malware. They slipped in one new dependency: plain-crypto-js. That dependency's postinstall hook silently downloaded a Remote Access Trojan onto Windows, macOS, and Linux machines. PowerShell on Windows. A C++ daemon on macOS. A Python script on Linux. Cross-platform, thorough, professional.

Microsoft attributed the attack to Sapphire Sleet, a North Korean state actor. Not some script kiddie. A government-backed hacking operation targeting the JavaScript supply chain.

The compromised window was roughly 4 hours. In those 4 hours, anyone who ran npm install in a project using axios got a RAT dropped on their machine. Or worse, on their CI/CD server, which typically has access to database credentials, API keys, and deployment tokens.

The fix was simple: roll back to axios v 1.14.0. But how many people noticed in time? And how many CI/CD pipelines ran automatically during that window?

This Isn't a Rare Event. It's the New Normal.

If you think this was a one-off, the numbers say otherwise.

Malicious npm packages went from 38 in 2018 to 2,168 in 2024 to 454,648 in 2025. That's not a typo. Four hundred fifty-four thousand malicious packages published to npm in a single year. In Q4 2025 alone, Sonatype blocked over 120,000 malware attacks. 99.8% of all open-source malware originated from npm specifically.

In September 2025, something even scarier happened. The Shai-Hulud worm became the first self-replicating npm worm. It spread autonomously across 500+ packages and temporarily trojanized projects from Zapier, PostHog, Postman, and ENS Domains. A separate phishing attack that same month compromised chalk, debug, ansi-styles, and strip-ansi, packages with a combined 2.6 billion weekly downloads. Let that sink in.

I wrote about the security problems that come with AI-generated code earlier this year. The supply chain angle is the same fundamental issue: we're trusting code we didn't write and often can't verify.

The Real Problem: You're Running Code You've Never Read

Here's an experiment. Go create a fresh Next.js app right now. Run create-next-app. Look at your package.json. You'll see maybe 5 to 10 explicit dependencies. Makes sense.

Now look at your node_modules folder. 300+ packages. Each one of them can run arbitrary code on your machine the moment you run npm install. No prompts. No confirmation. No audit. Just blind trust.

Think about it like this: you hired a contractor to build your house. They subcontracted 200 other people. You've met none of them. You don't know their names. You don't know their qualifications. But they all have keys to your front door.

That's what npm install does. Every time.

The ecosystem relies on trust chains that break silently. npm's design means any package can execute code at install time, on your machine, with your permissions. And when something goes wrong, there's no alarm. No notification. Just a trojan running quietly in the background.

I've written about how Claude is great at building software and also great at breaking it. AI-assisted development makes this problem worse, not better. Vibe-coded projects tend to be more dependency-heavy because it's faster to npm install a package than to write the functionality yourself. More dependencies means more attack surface that nobody audits.

Why Small Websites Get Hit Harder Than Big Companies

Large enterprises have security operations centers. They have Software Bill of Materials tooling. Vulnerability scanners running 24/7. Dedicated security teams whose entire job is watching for exactly this kind of thing.

A one-person agency has none of that. Neither does a 3-person startup. Neither does the local plumber whose website you built last month.

The blast radius is different too. If a RAT lands on a CI/CD server that holds your client's database credentials, their Stripe API keys, their email service tokens, all stored as environment variables, that's not a theoretical risk. That's your client's customer data walking out the door.

Wiz found that the axios malware executed in roughly 3% of impacted environments. Three percent of 100 million weekly downloads. That's 3 million executions.

Small businesses deploy from personal laptops. They store secrets as plain .env files. They run builds on shared hosting. They have no incident response plan. And they have no way to even know if they were hit.

This is the same pattern I see with SaaS stacks bleeding businesses dry: we run software from strangers, and when things go wrong, there's no support desk to call.

Five Things You Can Actually Do (That Aren't Enterprise SBOM Tools)

I'm not going to tell you to implement a full Software Bill of Materials pipeline. You're a freelancer. You don't have time for that. Here are five things that actually scale down to a solo developer or small team.

1. Use npm ci in your deploy pipeline, not npm install. This is the single biggest change you can make. npm ci installs from the lockfile exactly. npm install may silently upgrade packages to newer versions, which is exactly how the axios attack propagated. One line of config in your build step. Huge difference.

2. Commit your lockfile and never auto-update it. Your package-lock.json or yarn.lock pins exact versions. Treat any automated PR that bumps dependencies as requiring a human review. Not just a merge click. An actual look at what changed and why.

3. Add Socket to your GitHub. Socket.dev is free for open source and cheap for small teams. It scans pull requests for supply chain threats in real time. Takes two minutes to install. This is the one enterprise-grade tool that actually scales down to a solo developer.

4. Install with --ignore-scripts where possible. Running npm install --ignore-scripts prevents postinstall hooks from executing. Postinstall hooks were the attack vector in the axios compromise, the Shai-Hulud worm, and the chalk attack. Most packages don't need them. The malicious ones always do.

5. Wait before upgrading to a new major version. Most npm supply chain attacks are detected and removed within hours or days. A simple 7-day delay policy on upgrading to new releases would have completely blocked the entire axios attack window. You don't need to be on the bleeding edge. Let other people find the mines first.

I wrote about fixing my Next.js build pipeline earlier this year. Build pipelines deserve scrutiny, not just for performance but for security. If your deploy runs npm install instead of npm ci, you're rolling the dice every time you push.

I Checked My Own Projects. You Should Check Yours.

After the axios news broke, I went and checked my own projects. I wasn't using the compromised version. But I was using packages with over 200 transitive dependencies, and I'd audited exactly none of them.

I added Socket to my GitHub that afternoon. I switched my deploy scripts to npm ci. I started using --ignore-scripts for local installs. Took about 30 minutes total.

There's no silver bullet here. You can do all five things above and still get hit by a zero-day. The goal isn't perfect security. The goal is raising the cost of attacking you and reducing the blast radius when something slips through.

I'm not a security researcher. But I ship websites with 300+ packages in them, and so do you. The least we can do is stop pretending the supply chain is someone else's problem.

If you want a second pair of eyes on your stack before you ship, or you're wondering what else might be lurking in your node_modules, that's the kind of thing I do at wunderlandmedia.com. No fear-mongering. Just an honest look at what's actually running on your server.