Mastra npm compromise turns AI agent builds into credential-

The Mastra npm incident is a sharp warning for teams building AI agents: dependency compromise is no longer just a problem for traditional web applications. Microsoft, JFrog, Socket, StepSecurity, Orca Security, and other researchers have documented a campaign in which a hijacked npm maintainer account was used to republish more than 140 packages in the Mastra AI framework ecosystem with a malicious dependency called easy-day-js.

The affected packages were not simply defaced or broken. They pulled in a typosquatted dependency that executed during installation, fetched a second-stage payload, and targeted developer systems, build agents, cryptocurrency wallets, cloud credentials, and LLM API keys. Microsoft later attributed the activity with high confidence to Sapphire Sleet, a North Korea-linked actor also tracked as BlueNoroff.

For defenders, this is bigger than one package namespace. It shows how AI development stacks can become a high-value malware delivery path when package publishing rights, install scripts, and automatic dependency resolution line up in the attacker's favor.

What happened

Researchers report that the campaign began with control of the ehindero npm maintainer account, which still had publish rights across the Mastra ecosystem. On June 17, 2026, the attacker republished a large set of @mastra/* packages and added easy-day-js as a dependency.

That name was deliberately close to dayjs, a legitimate and widely used JavaScript date library. JFrog's registry timeline shows a clean-looking [email protected] was published on June 16, followed by weaponized [email protected] on June 17. The affected Mastra packages then declared a dependency range that allowed npm to resolve the newer malicious version automatically.

This is the quiet part of the attack. The compromised Mastra package code did not need to contain the main payload. The malicious behavior was pushed one level down into a dependency that looked plausible enough to pass a quick review.

Why the postinstall hook matters

The real risk came from npm's lifecycle behavior. The malicious easy-day-js package used an obfuscated postinstall script, which runs automatically after installation. Researchers say that script disabled TLS verification, wrote temporary markers, downloaded a second-stage payload from attacker infrastructure, launched it in the background, and attempted to remove traces of the initial loader.

That means a normal npm install could become code execution on a developer laptop, CI runner, or build host. No production deployment was required. No user needed to open a malicious document. The install process itself became the execution path.

This is why the incident belongs in incident response, not only software composition analysis. If an affected system installed the poisoned dependency during the exposure window, defenders should not treat the event as a harmless dependency alert. They should assume credentials and local secrets may have been exposed.

What the payload targeted

Public research points to a cross-platform infostealer and remote-access payload. Orca Security says the malware targeted browser data from Chrome, Edge, and Brave, 166 cryptocurrency wallet extensions, host reconnaissance data, and persistence across Windows, macOS, and Linux. StepSecurity and Socket reported that the affected packages represented more than 1.1 million combined weekly downloads, with @mastra/core alone accounting for a large share of the ecosystem's reach.

The target set tells the story. AI developer environments often hold:

LLM provider API keys
GitHub and npm tokens
cloud provider credentials
CI/CD secrets
SSH keys
database credentials
cryptocurrency wallet material
internal service tokens used by agent frameworks

That makes this a high-value identity and access management problem. The attacker does not need to compromise the final AI application if they can steal the credentials used to build, test, deploy, and operate it.

Why AI frameworks are attractive targets

AI agent frameworks sit at an uncomfortable intersection of trust. They are developer tools, automation platforms, and credential brokers at the same time. A single project may connect to OpenAI, Anthropic, cloud storage, internal databases, vector stores, GitHub, Slack, payment systems, and deployment pipelines.

That creates a richer blast radius than many teams expect from an npm dependency. A poisoned package in an AI framework can reach local .env files, CI variables, agent tool credentials, and secrets used for experiments that never passed through formal production controls.

Microsoft's attribution also matters. Sapphire Sleet has a documented history of targeting cryptocurrency and financial systems. In this case, the campaign blends that objective with developer-targeted supply chain tradecraft. The result is not just "steal wallets"; it is "steal the keys developers use to build systems that move money, data, and automation."

What defenders should do now

1. Search for affected packages and the malicious dependency

Check application repositories, lockfiles, container images, build caches, developer workstations, and CI runners for @mastra/*, mastra, create-mastra, and easy-day-js.

Fast local checks can start with:

bash
npm ls easy-day-js
rg "easy-day-js|@mastra/|create-mastra|\"mastra\"" package.json package-lock.json pnpm-lock.yaml yarn.lock

Do not stop at the main branch. Include old feature branches, internal templates, sample applications, and AI experiments that may still run in automation.

2. Treat affected hosts as potentially compromised

If a developer machine, CI runner, or build host installed the malicious dependency, isolate it and investigate before returning it to normal use. Package removal alone is not enough if the second-stage payload established persistence or stole secrets.

Use the persistence paths and indicators published by researchers as starting points. Orca lists Windows, macOS, and Linux locations used by the payload, and multiple vendors list the same Hostwinds IP infrastructure as network IOCs.

3. Rotate secrets with build context in mind

Prioritize credentials that were present on affected systems at install time:

npm access tokens and maintainer credentials
GitHub tokens and deploy keys
cloud provider keys
LLM API keys
CI/CD variables and environment secrets
SSH keys and database passwords
wallet seed phrases or keys exposed on affected systems

Secret rotation should include revocation and log review. If a token was stolen and used quickly, simply replacing it may hide the evidence trail defenders need.

4. Restrict install-time script execution where possible

Install scripts are powerful because some legitimate packages need build steps. But they are also one of the easiest ways for a dependency to execute code during installation.

Teams should consider --ignore-scripts for dependency review jobs, hardened CI lanes for untrusted dependency updates, and allowlists for packages that truly require lifecycle scripts. This will not eliminate supply chain risk, but it reduces the number of places where dependency resolution automatically becomes code execution.

5. Audit stale publisher access

The root operational failure was not only that a malicious dependency existed. It was that an account with publishing rights could still push package changes across a broad ecosystem.

Maintainers should review npm organization members, enforce phishing-resistant MFA where available, remove stale contributors, separate release automation from human accounts, and require provenance-backed releases. For large frameworks, package publishing should be treated like production deployment, not routine repository housekeeping.

Strategic takeaway

The Mastra compromise is a useful case study because the attacker did not need a CVE. They used identity compromise, semver behavior, a typosquatted dependency, and npm lifecycle scripts to turn normal AI development activity into a credential-theft path.

That is the modern software supply chain problem in plain terms: trust is executed automatically. If a package manager, CI runner, or developer machine trusts a dependency enough to run code during install, attackers will try to become that dependency.

For security teams supporting AI development, the response should be practical:

inventory AI framework dependencies
hunt for easy-day-js
isolate affected systems
rotate exposed secrets
review npm publisher access
limit install-time script execution in CI
treat developer workstations as part of the production risk surface

AI development is moving fast, but the trust model underneath it is still software supply chain trust. The Mastra incident shows how quickly that trust can be turned against defenders when package publishing rights are left too broad and installation is allowed to execute code by default.

What is the Mastra npm supply chain attack?

It is a June 2026 compromise in which a hijacked npm maintainer account republished more than 140 Mastra AI framework packages with a malicious easy-day-js dependency that ran during installation.

Is there a CVE for this incident?

No. This is a package supply chain compromise, not a conventional software vulnerability with a CVE. That makes dependency inventory, lockfile review, and behavioral detection especially important.

What systems are at risk?

Developer workstations, CI runners, build servers, containers, and projects that installed affected Mastra packages or resolved [email protected] during the exposure window should be treated as potentially compromised.

What should teams rotate first?

Start with npm tokens, GitHub credentials, cloud keys, LLM API keys, CI/CD secrets, SSH keys, database credentials, and any cryptocurrency wallet material present on affected systems.

Mastra npm compromise turns AI agent builds into credential-theft risk