SURIQ
Here is the part of the Mastra npm compromise that should worry you most: the malicious dependency passed review. On June 16 it was a clean, working copy of a popular date library. A day later the same package name shipped a version that stole cryptocurrency wallets and opened a remote shell. Any scan, any human eyeball, any policy check that ran against the first version saw nothing wrong. The attack was not hidden in obfuscation. It was hidden in time.
On June 17, 2026, attackers pushed poisoned releases of more than 140 packages drawn from the two Mastra namespaces on npm, mastra and @mastra. Microsoft Threat Intelligence and Snyk both traced the compromise to a single hijacked maintainer account. Mastra is a widely used framework for building artificial intelligence agents, and that is not an accident. Its packages are pulled into projects by developers who tend to keep cloud and model credentials within arm's reach.
What actually happened?
The entry point was an account, not a vulnerability. The @mastra scope still listed a maintainer named ehindero, a contributor who had gone quiet long ago. Snyk read the evidence as a stolen login rather than a rogue insider, citing an email address quietly switched off the contributor's own. The root cause is a quiet piece of npm's design: publish permissions on a scope do not expire when a maintainer goes dormant. One forgotten login could publish to every package the scope owned.
With that access, the attacker added a dependency named easy-day-js to the Mastra packages. It is a typosquat of dayjs, a date library that sees tens of millions of downloads a week. The fake was built to survive a glance: Snyk describes it as a near byte-for-byte copy of the real thing, matching the version numbers, author metadata, and repository links of the genuine package.
The timing is the trick. Microsoft's account shows the bait laid first: a harmless build, [email protected], went up on June 16 at 07:05 UTC carrying no install hooks. The weaponized build, 1.11.22, followed on June 17 at 01:01 UTC and seized the latest tag. Since it fit the version range the Mastra packages declared, an ordinary npm install walked straight into it. Snyk clocks the mass republish of the Mastra packages themselves at roughly 01:12 to 02:36 UTC that same morning.
What does the payload do?
The malicious version carried a postinstall hook, the script that npm runs automatically when a package is installed. Microsoft pulled that script apart, setup.cjs, and the steps are deliberate. First it flips NODE_TLS_REJECT_UNAUTHORIZED to 0, killing certificate checks so a proxy cannot read what comes next. Then it reaches out to attacker servers, fetches a follow-on program of roughly 41 kilobytes, launches that program as a hidden, fully detached process, and scrubs the evidence of itself.
That follow-on program is where the theft happens. Microsoft describes a tool that runs on every major operating system, hunts for cryptocurrency wallet browser add-ons against a list of 166 known identifiers, lifts browsing history, fingerprints the machine, and hands the operator a live shell. It digs in for persistence on Windows, macOS, and Linux and checks in with its controllers at a steady cadence. This is theft plus a foothold, not a smash-and-grab.
Who is actually exposed?
The download numbers tell you the surface area. Snyk reports that @mastra/core alone draws roughly 4 million downloads a month, with mastra adding around 1.5 million more. Not every one of those resolved the bad version, but the window was open for hours during a busy build period.
The bigger point is where the damage lands. A developer laptop that installed the package is one exposed wallet. A continuous integration and deployment build agent that ran npm install is a different problem entirely. Postinstall scripts execute with whatever the build holds: cloud keys, deployment tokens, npm publish tokens, signing keys, and the model API keys that an artificial intelligence project keeps handy. That is how one poisoned dependency turns into an organization's secret store. If you only think about this as a crypto-stealer, you will under-scope your response.
The pattern worth internalizing
Three things about this compromise generalize past Mastra.
First, point-in-time vetting is the wrong model for a moving target. Most teams review a dependency once, when they add it or when a scanner flags it, and trust the result. The clean-then-armed sequence is built to defeat exactly that habit. The package you approved on Monday is not the package that installs on Tuesday. Detection has to watch what an install does, not just what a package once was.
Second, the behavior here is loud even though the code was quiet. A postinstall script that disables TLS validation and spawns a detached background process is not normal, and it is observable at install time on the host. Reputation-based defense fails when the reputation is freshly minted and clean. Behavioral detection at the moment of install does not care that the package looked fine yesterday.
Third, artificial intelligence tooling is now a named target, not collateral. The attacker picked a fast-moving framework whose users sit close to valuable keys. This is the same logic behind malicious developer plugins that harvest model API keys, and it rhymes with supply chain backdoors that only fire under the right conditions. Developer infrastructure is the breach now.
What to do this week
Treat this as remediation, not monitoring. Pin Mastra packages to known-clean versions; Microsoft names the last pre-incident baselines as mastra through 1.13.0 and @mastra/core through 1.42.0, and Snyk argues that rolling forward to a fixed release beats downgrading once one exists. Run installs with --ignore-scripts so postinstall hooks cannot fire blind. Then rotate, on the assumption of compromise for any machine that installed the bad version: cloud keys, build tokens, npm tokens, SSH keys, and model API keys. Move cryptocurrency out of any wallet that lived on an affected host. Block the command-and-control addresses Microsoft published, and hunt for the temporary artifacts it lists.
On attribution, be precise
The two primary write-ups do not fully agree on who did this, and it is worth stating plainly rather than picking one. Microsoft puts its name on the call: it ties the activity, with high confidence, to Sapphire Sleet, a North Korean state-sponsored group it also tracks under labels including BlueNoroff. Snyk holds back, saying it will not confirm attribution for this particular intrusion while granting that the methods line up closely with an earlier npm break-in Microsoft pinned on the same crew. Both positions can hold. A high-confidence vendor assessment is a strong signal, and an independent researcher declining to co-sign it is normal. For a defender, the actor matters less than the method, and the method is well documented either way.