Mastra npm supply chain attack hits AI build rooms

A package install is now enough to make your AI app leak like a badly scoped admin token. The Mastra npm supply chain attack matters because it hit the machinery builders use before code reaches production: dependency resolution, CI runners, developer laptops, and the secrets sitting around them.

Microsoft says the campaign affected more than 140 packages across the mastra and @mastra scopes, and on June 19, 2026, the company attributed the activity with high confidence to Sapphire Sleet, a North Korean state actor also known in public reporting as BlueNoroff. Microsoft Threat Intelligence said the attackers took over the ehindero npm maintainer account, injected a malicious dependency called easy-day-js, and used npm install behavior to run a postinstall payload.

That should change your incident response posture. If your team installed affected Mastra packages during the exposure window, this is a build pipeline and secret exposure incident, not a dependency hygiene chore. The same lesson sits underneath our Fortinet guide on why credential exposure needs a reset plan: once attackers can touch the place where secrets live, cleanup without rotation is theater.

What actually happened inside the Mastra npm packages?

The attacker used one compromised npm maintainer account to publish poisoned Mastra package versions that added easy-day-js@^1.11.21 as a new dependency. Microsoft reported that every package published by the compromised ehindero account contained the injected dependency, while packages last published through GitHub Actions CI/CD or other legitimate maintainers were unaffected.

The trick was small enough to hide in a noisy dependency diff. Microsoft observed that [email protected] had been published through GitHub Actions OpenID Connect, while [email protected] was manually published by ehindero using a Tutamail address. The same Microsoft analysis says the only package change between those two versions was the addition of easy-day-js@^1.11.21.

The malicious dependency impersonated dayjs, the legitimate date library. Microsoft’s comparison says the real dayjs package had 57,251,792 weekly downloads, while easy-day-js was newly created and had only two versions, both published in June 2026. That gap matters because the name was close enough for a human skim, while the registry metadata screamed that something was off.

The staged delivery pattern made the compromise more dangerous. Microsoft’s timeline says [email protected] was published at 07:05 UTC on June 16, 2026 as clean bait, [email protected] was published at 01:01 UTC on June 17 with the postinstall payload, and [email protected] plus more than 140 other @mastra packages followed at 01:20 UTC.

That timing is the whole move. A package manifest that says ^1.11.21 can resolve to 1.11.22, so a fresh install can pick up the weaponized version even though the injected line names the earlier version range. JFrog’s independent analysis reached the same conclusion and found that fresh installs resolving easy-day-js@^1.11.21 selected the payload bearing 1.11.22 release. JFrog Security Research wrote that the affected Mastra code was largely untouched and that the malicious behavior moved one dependency lower.

The chart below shows the key operator numbers: Microsoft reported more than 140 affected packages, a 4,572 byte first stage dropper, a roughly 41 KB second stage Node.js tasking client, 166 wallet browser extension IDs checked, and 7 high level attack phases.

These are not vanity metrics. They describe where to hunt. If you only check application imports, you miss the install hook. If you only scan the package tarball, you may miss a second stage fetched at runtime. If you only rotate production secrets, you may leave developer tokens and CI credentials exposed.

Why does this hit AI app builders harder than a normal npm scare?

Mastra is used in the AI agent and workflow ecosystem, which means affected environments are unusually likely to contain valuable service credentials. Microsoft said any developer workstation or CI/CD pipeline that ran npm install or npm update after the compromised versions were published was potentially exposed, regardless of whether the package was imported in application code. That warning points directly at LLM API keys, cloud credentials, build tokens, npm publish rights, and downstream software integrity.

AI build environments tend to be credential dense. A modern agent service can hold provider keys for OpenAI, Anthropic, Google, vector database credentials, GitHub tokens, observability keys, database URLs, and deployment secrets. One laptop with a permissive .env file can be more useful to an attacker than a single production pod with tight workload identity.

The payload was built for that kind of host. Microsoft said the postinstall hook launched an obfuscated 4,572 byte dropper, disabled TLS certificate verification, contacted attacker controlled C2 infrastructure, downloaded a second stage payload, and ran it as a detached hidden process. Microsoft’s payload analysis also says the second stage installed persistence across Windows, macOS, and Linux.

The persistence paths read like a developer workstation bingo card. Microsoft documented a Windows Registry Run key, a macOS LaunchAgent, and a Linux systemd user service, all using names designed to blend into Node.js or NVM related directories. The article says the dropped implant used a misspelled protocal.cjs file name and Node themed paths such as NodePackages or nvmconf.

The wallet targeting was explicit. Microsoft found a hardcoded list of 166 cryptocurrency wallet browser extension IDs, including MetaMask, Phantom, Coinbase Wallet, Binance Wallet, and TronLink, matched across Chrome, Edge, and Brave profiles.

That crypto focus fits the actor. Microsoft says Sapphire Sleet has been active since at least March 2020 and primarily targets finance, cryptocurrency, venture capital, and blockchain organizations. Microsoft’s actor profile in the Mastra report says the group’s primary motivation is stealing cryptocurrency wallets and technology tied to cryptocurrency trading and blockchain platforms.

The campaign also connects to a broader npm pattern. On March 31, 2026, Microsoft identified two malicious Axios versions, 1.14.1 and 0.30.4, that used a fake dependency to fetch a second stage RAT from Sapphire Sleet infrastructure. Microsoft’s Axios writeup said Axios had more than 70 million weekly downloads and that affected users should rotate secrets immediately.

Here is the operator read: AI dependencies are becoming a path into the build system, and the build system is becoming a path into the business. If an attacker steals your LLM key, they can burn budget. If they steal your GitHub token, they can alter code. If they steal a cloud key from CI, they can reach data and deploy infrastructure. If they steal an npm token, they can turn you into the next distribution layer.

What should you do in the first 24 hours if Mastra touched your builds?

Start with exposure, then move to containment. Microsoft says the compromised packages have been removed and the attacker’s publish access to the @mastra scope has been revoked, but that does not clean already exposed machines or runners. Microsoft’s mitigation guidance tells teams to review dependency trees, search for easy-day-js, pin known good versions, use --ignore-scripts, rotate exposed credentials, and block the C2 IP addresses 23.254.164.92 and 23.254.164.123.

Run the boring searches first. Boring is how you win before lunch.

npm ls easy-day-js
find . -name package-lock.json -o -name npm-shrinkwrap.json | xargs grep -n "easy-day-js"
grep -R "@mastra\|easy-day-js" ~/.npm 2>/dev/null

Then check endpoints and runners for host indicators. Microsoft lists $TMPDIR/.pkg_history, $TMPDIR/.pkg_logs, unexpected .js files in home or temp directories, the protocal.cjs implant, the teams.onweblive.org post compromise delivery domain, and the maskasd.com beacon domain as indicators. The Microsoft IOC table also includes SHA-256 hashes for setup.cjs, easy-day-js-1.11.22.tgz, and mastra-1.13.1.tgz.

Treat any positive hit as credential compromise. Rotate LLM provider keys, GitHub tokens, npm tokens, cloud access keys, database passwords, package registry credentials, CI secrets, and any wallet or signing material reachable from that host. If the host is a long lived CI runner, rebuild it from a clean image instead of trying to disinfect it in place.

Your response checklist should be short and strict:

• Freeze dependency updates for affected repos until you have a clean lockfile and a known good Mastra version.
• Search every repo, developer workstation, CI cache, container build context, and artifact store for easy-day-js.
• Rebuild runners and workstations that executed the compromised install, especially if they held production deploy rights.
• Rotate every secret accessible to those hosts, even if logs show no obvious exfiltration.
• Add egress detections for 23.254.164.92, 23.254.164.123, teams.onweblive.org, and maskasd.com.
• Add process detections for Node.js running setup.cjs, easy-day-js, hidden PowerShell, and unexpected Node processes from temp paths.

Do not wait for a CVE. Corgea’s incident note lists the Mastra compromise as having no CVE assigned, which is normal for many registry account takeovers and malicious package publications. Corgea’s breakdown frames the affected surface as compromised @mastra/* packages, top level mastra and create-mastra, developer workstations, and CI runners.

Which build controls should stay after the fire drill?

The strongest long term control is to reduce automatic code execution during install. GitHub says npm v12 is estimated for July 2026 and will turn several install behaviors into explicit opt ins, including dependency preinstall, install, and postinstall scripts. GitHub’s npm v12 changelog says allowScripts will default to off, Git dependencies will require --allow-git, and remote URL dependencies will require --allow-remote.

You do not need to wait for v12 to adopt the posture. GitHub says npm 11.16.0 or newer already shows warnings, and teams can run npm approve-scripts --allow-scripts-pending before approving trusted packages. The same GitHub guidance says the resulting allowlist is written to package.json and should be committed.

For production AI systems, make install scripts guilty until proven needed. That means npm ci --ignore-scripts in CI wherever possible, explicit allowlists where native builds make scripts unavoidable, and separate build jobs for dependencies that genuinely need compilation. Convenience should lose when a package manager wants to run code from the internet.

Pinning also matters, with nuance. Microsoft recommends pinning known good package versions where possible and says mastra version 1.13.0 and earlier, plus @mastra/core version 1.42.0 and earlier, were unaffected. Microsoft’s mitigation section also recommends removing easy-day-js from lockfiles and checking CI/CD logs for suspicious postinstall execution and C2 connections.

The business decision is where to spend friction. Put it on dependency publish and install paths, not on engineers trying to ship features at 6 p.m. A practical policy looks like this: trusted publishing for packages you own, ephemeral runners for sensitive builds, no long lived cloud keys on laptops, strict egress from CI, dependency script allowlists, and emergency rotation runbooks that include LLM keys.

This incident also argues for provenance alerts. Microsoft caught a suspicious shift from GitHub Actions OIDC publishing to a manual publish from an anonymous email address. That is a great detection pattern for any package your company depends on heavily: alert when a package version loses trusted publisher metadata, changes publisher identity, adds a new dependency, or gains a lifecycle script.

The build room is part of production now

The Mastra compromise is the kind of incident that punishes teams that draw a neat line between development and production. A stolen CI token can become a production incident. A stolen LLM key can become a cost incident. A stolen npm token can become a customer incident.

Your AI stack is only as clean as the machine that installed it.

Sources

• Microsoft Security Blog: From package to postinstall payload: Inside the Mastra npm supply chain compromise by Sapphire Sleet
• Microsoft Security Blog: Mitigating the Axios npm supply chain compromise
• GitHub Changelog: Upcoming breaking changes for npm v12
• JFrog Security Research: easy-day-js: Supply Chain Campaign Targets Mastra npm Packages
• Corgea Research: Mastra npm scope takeover used easy-day-js to Trojanize 141 to 143 packages
• BleepingComputer: Microsoft links Mastra AI supply chain attack to North Korean hackers