A North Korean Crew Backdoored 140+ Mastra Packages on June 17. If You Build Agents on Mastra, Your Framework Was the Attack.

In the early hours of June 17, between roughly 01:15 and 02:36 UTC, an attacker pushed malicious versions of 140-plus packages in the @mastra npm scope, the AI agent framework a lot of solo builders reach for when they want to ship an agent without writing the orchestration from scratch. The packages had a combined weekly download count north of a million. The payload was a cross-platform stealer that went after crypto wallets, browser data, and developer credentials, and security teams tied the tradecraft to Sapphire Sleet, the North Korean crew also tracked as BlueNoroff.

That last detail is the part worth sitting with. This wasn't a teenager farming install counts. A nation-state group spent its effort poisoning the framework people use to build AI agents, because that framework sits deep in your dev environment, next to your secrets, with permission to run code.

What actually happened

The mechanics are clean enough to be unsettling. On June 16 at 07:05 UTC, an npm account published easy-day-js version 1.11.21, a typosquat of the popular dayjs date library, and at that point a fully functional, completely clean copy with no malicious code. A real package with a believable history. The next night, a second account compromised the @mastra organization and added easy-day-js as a dependency across the Mastra package set, then published a weaponized version. The malicious release carried an obfuscated postinstall dropper that pulled a second-stage payload from an attacker server and then deleted itself to clean up the evidence.

Splitting the work across two accounts is the trick. The package that got pulled in had a clean prior version, so static analysis and "is this package suspicious" heuristics saw a normal date library with a real track record. The weaponization happened at the org level, after the trust was already established. By the time anyone diffed it, the dropper had already had a window to run during npm install.

That window is the whole game. A postinstall script runs automatically when you install, before any of your application code executes, with the privileges of whoever ran the install. On a CI runner, that's your pipeline secrets. On your laptop, that's your SSH keys, your .npmrc token, your browser session cookies, and your wallet.

Why this one is worse than the last npm story

We've all gotten a little numb to npm supply-chain headlines. There's been a steady drip of them this year, and the natural reaction is "yes, pin your deps, I know." But the target selection here is a genuine escalation, and it's worth being precise about why.

A random utility package getting backdoored is a numbers game: spray the payload, catch whatever credentials fall out. Poisoning an AI agent framework is targeting. The people who install @mastra are, by definition, building systems that hold API keys to model providers, often have access to a database or two, frequently run with cloud credentials in the environment, and increasingly have an actual crypto wallet somewhere in the stack. The framework is a concentrator of exactly the things this group wants to steal. They didn't get lucky with the target. They chose it.

And the agent angle compounds it. If your Mastra-built agent runs in production with tools wired up (a shell, a database client, a deploy hook), a compromised framework isn't just stealing your dev credentials. It's sitting inside a process you've deliberately given the ability to take actions. The blast radius of "the framework I build agents on was backdoored" is larger than the blast radius of "a date library was backdoored," because of what the framework is allowed to touch.

The part where being solo hurts

Here's the uncomfortable bit. An enterprise running Mastra has a security team that got a Microsoft Threat Intelligence advisory, a tool that flags new transitive dependencies, and an incident process that rotates credentials on a schedule. When the news broke, somebody whose actual job is this was already triaging.

You are the security team. On a one-person operation, the same npm install that pulls the malicious version also has nobody downstream to catch it. There's no second engineer reviewing the lockfile change, no SOC watching for the outbound connection to the dropper's server, no policy that quarantines a package published at 2am. The efficiency of solo operation (no coordination, no approvals, just ship) is the exact thing that removes the accidental safety net here. Nobody's slowing you down, which also means nobody's slowing down the payload.

The 15-minute Saturday check

This is the part you can actually do, and it's short. If you've installed anything in the @mastra scope, or anything that might pull easy-day-js transitively, treat any version installed after June 16 as suspect and work backward from there.

Start by checking whether the bad dependency is anywhere in your tree:

npm ls easy-day-js
grep -r "easy-day-js" package-lock.json

If it shows up, or if you installed or updated Mastra packages in the June 16–17 window, do the boring, correct thing: rotate everything the install could have touched. That means your npm token, any cloud credentials that were in the environment, SSH keys, and, if a wallet was anywhere near that machine, move the funds. Rotating credentials after the fact feels like overkill right up until the one time it isn't.

Then change the defaults so the next one of these is less dangerous. Turn off install scripts globally so a postinstall dropper can't just run on npm install:

npm config set ignore-scripts true

This breaks a handful of legitimate packages that genuinely need a build step, and you'll re-enable it deliberately for those. That friction is the point. Pin your dependencies to exact versions instead of caret ranges, and add a lockfile-lint or a "no dependencies newer than N days" gate to CI if you run one: most of these attacks rely on you pulling a brand-new version within hours of publication.

The honest take

I'm not going to tell you to drop Mastra. The framework didn't do anything wrong; the npm trust model did, and the same attack could land on any framework popular enough to be worth targeting. Switching frameworks just moves you to the next target. And the doom version of this, "AI agent frameworks are too dangerous to use," is wrong. They're fine. What's not fine is installing them the way we all install everything: caret ranges, install scripts on, no rotation discipline, pulling the freshest version the moment it publishes.

The fix isn't fear, it's friction in the right place. Pin versions. Kill install scripts by default. Don't auto-update to a release that's six hours old. Rotate credentials when something like this lands instead of hoping you weren't in the window. Those four habits cost you almost nothing on a normal week and save the entire operation on the bad one. Set them up this weekend, while the headline is fresh enough to make you actually do it.

Author

Lukas

@lukcombinator

Sources

• Mastra npm Supply Chain Attack: 140+ Packages Backdoored via easy-day-js Typosquat: StepSecurity
• From package to postinstall payload: Inside the Mastra npm supply chain compromise by Sapphire Sleet: Microsoft Security Blog
• Hackers Compromised 140+ Mastra npm Packages to Deploy Password-Stealing Malware: Cyber Security News
• Mastra npm Compromise: easy-day-js Attack & Response: Kodem