North Korean hackers poisoned 140+ npm packages of an AI framework — the Mastra attack and what it teaches

Every developer does it dozens of times a week without thinking: npm install. You trust that handful of packages — and their packages, and the packages of their packages — are what they claim to be. This week's attack is a hard reminder that this trust has a cost.

What happened?

Microsoft attributed, with "high confidence", to North Korea — the state group Sapphire Sleet (also known as BlueNoroff) — a supply-chain attack that compromised 140+ npm packages in the @mastra scope, tied to an AI framework in the Node/JavaScript ecosystem. Disclosure landed on June 19–20, 2026.

The way in was classic: the attackers hijacked a maintainer account (with publish rights) and injected a malicious dependency called easy-day-js — a typosquat of the legitimate dayjs library. Similar name, opposite intent.

How the attack worked

The decoy package abused a postinstall hook — a script npm runs automatically the moment the package is installed. Per the analysis, the chain was:

npm install            // you install the package (directly or transitively)
   └─ postinstall      // npm fires the script on its own
        └─ obfuscated dropper
             ├─ disables TLS certificate verification
             ├─ contacts the command-and-control (C2) server
             └─ downloads stage 2: a cross-platform info-stealer

Stage two was a data stealer for Windows, Linux and macOS. It swept 166 crypto-wallet extensions (MetaMask, Phantom, Coinbase and others), stole credentials, API keys, auth tokens and wallets, and installed persistence (Registry Run keys on Windows, LaunchAgents on macOS, systemd services on Linux) to survive a reboot.

Why this hits you even if you've never heard of Mastra

Because the danger isn't that package — it's the model. You install A, which depends on B, which depends on C. If C gets swapped for a malicious version, the code runs on your machine, at npm install time — before you run a single line of your project. And it's not "a Node problem": any project with a front-end — including mine, in PHP — pulls dozens of npm packages to build CSS and JS.

How to harden your dependencies

• Commit the lockfile and install with npm ci — it installs exactly what's in package-lock.json, without resolving new versions on its own.
• Turn off automatic scripts: npm install --ignore-scripts (or ignore-scripts=true in .npmrc). Run postinstall only for packages you trust.
• Don't install what just shipped. Wait a few days before adopting a freshly published version — most poisoned packages are caught and pulled within hours.
• Read the name carefully. easy-day-js is not dayjs. Typosquatting feeds on haste and autopilot.
• Run npm audit and consider a package-analysis service (e.g. Socket) in your CI.
• Keep secrets off your dev machine. Don't leave production keys and wallets on the same machine where you run npm install for random projects. It's the difference between "I installed a bad package" and "I lost everything."

My take

The strength of the npm ecosystem — reusing the whole world's work with one command — is also its biggest attack surface. I treat third-party dependencies as untrusted code by default: locked lockfile, scripts off, secrets isolated, and an eye on what enters the project. It's not paranoia — it's the cost of operating in an open ecosystem.

I want a security review of my project

Want a review of your project's dependencies and pipeline before a weak link becomes a headache? That's exactly the kind of thing I do — let's talk.

Sources

BleepingComputer · Microsoft Security (MSTIC)