Stolen npm Account Backdoored More Than 140 Mastra Packages

An attacker with control of an npm publisher account pushed poisoned releases across more than 140 packages in the Mastra AI framework on June 17. Each release added easy-day-js, a typosquat that ran malware during installation. Application code never had to import it.

Microsoft Threat Intelligence attributed the operation with high confidence to Sapphire Sleet, a North Korean state actor also tracked as BlueNoroff. The group turned a maintainer credential into an automated route through developer workstations and CI runners.

One dependency changed the install path

The publisher history gave investigators an unusually useful signal. Microsoft found that Mastra releases through version 1.13.0 came from a GitHub Actions workflow using OpenID Connect. Version 1.13.1 arrived as a manual publish from the compromised ehindero account. The corresponding source repository contained no code change, yet the npm package gained a new dependency: easy-day-js@^1.11.21.

The attacker had prepared that dependency in two steps. A clean version, 1.11.21, appeared on June 16 and copied the identity of the legitimate dayjs project. Version 1.11.22 followed at 01:01 UTC the next day with an obfuscated setup.cjs file and a postinstall command. The caret range in the Mastra packages caused fresh installs to resolve to the weaponized release.

That sequence separated package review from execution. A reviewer could inspect the clean dependency, approve a Mastra update and still receive different code when npm resolved the version later.

The installer opened the door

The 4,572-byte dropper disabled TLS certificate verification, wrote tracking files in the operating system’s temporary directory and fetched a second-stage JavaScript payload from attacker infrastructure. It launched that code as a detached, hidden Node.js process and removed its own setup file.

Microsoft’s analysis found a cross-platform tasking client with persistence, host reconnaissance, browser-history collection and cryptocurrency-wallet discovery. On Windows, the campaign also used reflective .NET loading and a separate PowerShell backdoor. Microsoft observed later activity that added Defender exclusions and installed a service for SYSTEM-level persistence.

StepSecurity reproduced the install path with @mastra/[email protected] in a controlled GitHub Actions job. Its runner blocked the first outbound connection, which prevented the second stage from reaching the test system. That result confirms a useful containment point; it does not tell an exposed organization whether an earlier install completed.

Microsoft said any workstation or CI/CD pipeline that ran npm install or npm update after the poisoned releases appeared was potentially exposed. A lockfile may answer whether the malicious version resolved. Install logs and package-manager caches can show when it arrived. Neither proves that the postinstall process failed, so responders also need process, file and network evidence.

AI build environments carry an attractive credential set

This was an npm supply-chain attack against an AI framework, rather than an attack performed by an autonomous agent. The distinction keeps the analysis honest while leaving a serious exposure problem.

Mastra projects commonly connect to model providers, source repositories, databases, vector stores and deployment platforms. Their build jobs may hold API keys and cloud credentials needed to assemble or deploy an agent. Code that runs during package installation inherits whatever the job exposes, even before the framework starts.

The immediate inventory should therefore connect package evidence to identity. Find systems that resolved affected Mastra versions or [email protected], then identify the credentials available to each install process. Microsoft also published file and network indicators, including .pkg_history, .pkg_logs and the two IP addresses used by the first stages. Where execution remains possible, isolate the host, investigate persistence and rotate every credential the process could read. Removing the package alone leaves stolen access usable.

Publisher drift deserves its own alert

The switch from OIDC-backed publishing to a manual account was visible before anyone deobfuscated the payload. So was a new transitive dependency with no matching source change. Those are strong release-integrity signals because they describe how an artifact was produced, rather than guessing whether its JavaScript looks malicious.

Teams can make those signals actionable by recording the expected publisher and provenance for important packages, then stopping upgrades when either changes. Lockfiles and npm ci keep dependency resolution repeatable. A registry delay for very new versions can also prevent a clean bait package from becoming a weaponized dependency between review and installation.

Lifecycle scripts need comparable scrutiny. Some projects require them, so a blanket --ignore-scripts policy may break legitimate builds. An explicit allowlist, isolated install stage and restricted outbound access provide a workable alternative. Secrets should enter only after untrusted installation steps have finished.

The Mastra compromise gives defenders a specific question for every build: did the artifact, publisher or dependency graph change between source review and execution? Answering it requires provenance and runtime evidence together. That is far more useful than treating a successful vulnerability scan as permission to let an installer run beside production credentials.

Verify a clean build by matching the artifact, publisher and dependency graph to the approved provenance record, then confirm that installation completes without deployment credentials or unexplained outbound connections. A mismatch keeps the release blocked.