Mastra npm supply chain compromise shows semver can hide malicious code

At a glance

What this is: A compromised Mastra npm scope used a one-line dependency change to make fresh installs pull malicious code at install time, even when the visible package content looked clean.

Why it matters: AppSec and identity teams need to treat published registry metadata, dependency resolution, and install-time execution as part of the trust boundary for developer workstations, CI runners, and any environment holding high-value secrets.

By the numbers:

• Corgea says the attack affected 141 compromised @mastra/* packages plus the top-level mastra and create-mastra packages published on 17 June 2026.
• Corgea says fresh installs that resolved [email protected] could execute attacker-controlled code at install time.
• Corgea says Microsoft observed 166 hardcoded browser-wallet extension IDs across Chrome, Edge, and Brave in the later-stage implant.

Context

Mastra is an AI agent framework, so its dependency tree sits close to the systems that build, deploy, and operate applications holding credentials, tokens, and other secrets. In this incident, the real attack surface was not only the source repository, but the published npm artifacts, the registry metadata, and the semver resolution rules that decided what code executed during install.

Supply-chain compromise matters here because the attacker did not need to alter the obvious application source to reach runtime execution. A fresh install that resolved the malicious dependency turned package management into code execution, which is exactly why AppSec teams need to treat dependency publishing as part of software trust governance, not just build hygiene.

Key questions

Q: What breaks when a package adds a malicious dependency through semver?

A: A clean-looking package can still execute attacker-controlled code if a version range resolves to a malicious patch release. The break is in the trust model, not just the source code, because install-time resolution can replace an inspected dependency with a different artifact after review. Teams need to validate what the registry actually served, not only what the repository showed.

Q: Why do credential-harvesting supply chain attacks create so much downstream risk?

A: Because stolen machine credentials are often more reusable than the code path that exposed them. A valid token can be used to publish packages, write tags, access registries, or reach SaaS and cloud resources without triggering a new authentication event. The business impact is broad because one compromise can propagate into multiple environments and user bases.

Q: What are the signs that a package release may have been tampered with?

A: Warning signs include a registry release with no matching Git tag, no corresponding commit history, unusual publication timing, and rapid community alerts from security researchers. When those signals appear together, the release deserves immediate scrutiny. Security teams should also watch for automated dependency tools proposing upgrades to the suspicious version before manual validation is complete.

Q: How should teams respond when a fresh install could have executed malicious code?

A: Treat the installation as a host compromise until proven otherwise. Isolate the machine, preserve lockfiles and package caches, inspect for install-time hooks and follow-on processes, and rotate any secrets that were reachable from the affected environment. If persistence or C2 is present, scope the incident as an intrusion, not a dependency cleanup.

Technical breakdown

How a semver carrier package turns a clean-looking release into code execution

The core trick was to publish a harmless-looking dependency name, then use a version range in the parent package so npm selected the attacker-controlled patch release. In practice, the visible package can look ordinary while the executable logic sits one dependency lower, which is why source diff review alone misses the compromise path. The malicious tarball does not need to be obviously weaponised if install-time hooks such as postinstall are enough to run code before developers inspect the tree. Practical implication: review registry resolution paths, not just repository diffs, whenever a package adds or updates a dependency range.

Practical implication: Inspect published package metadata and dependency ranges as part of release approval, because semver can redirect installs to malicious payloads.

Why install hooks and registry provenance matter more than package appearance

Install-time scripts are powerful because they run during dependency installation, before the application starts and often before defenders notice anything unusual. The article shows how a postinstall hook, combined with a downloaded second-stage payload, can keep malicious logic out of the visible library code. Provenance also matters because a package that normally publishes from CI can suddenly appear as a manual release from a hijacked account, and that metadata break is often the clearest compromise signal. Practical implication: treat unexpected publisher changes, manual publishes, and install hooks as high-risk indicators that require triage.

Practical implication: Block or inspect packages with install hooks and anomalous publish provenance before allowing them into build and runner environments.

Why node-based supply chain attacks now overlap with secrets and identity abuse

This compromise is not only about arbitrary code execution. Once malicious code runs inside a developer workstation or CI runner, it can reach cloud credentials, GitHub tokens, npm tokens, browser data, and AI provider keys that are often available to Node.js processes. That creates an identity and NHI governance problem because machine credentials and delegated access can be harvested from the same environment that built the software. Practical implication: constrain what secrets are reachable from build and development contexts, and assume an install-time compromise can pivot into credential theft and later persistence.

Practical implication: Reduce secret exposure in build and developer environments, because install-time code can pivot directly into credential harvesting.

Threat narrative

Attacker objective: Use a trusted package update to gain execution on developer and CI hosts, then steal secrets and establish persistence for follow-on access.

1. Entry occurred when the attacker republished the @mastra npm scope with a one-line dependency change that made fresh installs resolve the malicious easy-day-js package.
2. Credential access followed when the install-time dropper ran under Node.js and searched environments that could expose cloud credentials, GitHub tokens, npm tokens, browser data, or wallet data.
3. Escalation and persistence followed when the second stage fetched a remote payload, wrote temporary code, and in some cases installed OS-level persistence on Windows, macOS, or Linux hosts.
4. Impact was full host compromise with follow-on control, making affected developer workstations and CI runners part of an operator-controlled intrusion path rather than a simple dependency incident.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Semver carrier packages are now a real trust boundary: the attack did not rely on visibly malicious application code, only on a dependency range that resolved to a harmful patch release. That means package review has to include registry metadata, publish provenance, and install-time behaviour, not just repository contents. For AppSec teams, this is a release-governance problem as much as a code-review problem.

Install hooks are an execution boundary, not a convenience feature: postinstall scripts can turn a dependency fetch into code execution before a developer or runner ever starts the application. In supply-chain response, the important question is no longer only whether the package looks clean, but whether its install path can execute unaudited logic. Teams should treat install-time execution as a separate approval gate.

This incident collapses the line between software supply chain and identity governance: once the package ran on a workstation or runner, the practical target set included cloud credentials, GitHub tokens, npm tokens, and AI-provider keys. That is where NHI governance becomes relevant, because machine credentials exposed to build systems are now part of the attacker’s post-install prize. The control gap is not just package trust, but secret reachability.

Publish provenance should be treated as a detection signal, not background noise: the article’s manual publish path and account abuse are the kind of metadata shifts that should stand out in registry monitoring. A package that normally publishes from CI but suddenly appears from a personal mailbox or different release path should move to the front of the triage queue. That is the difference between a suspicious update and a proven supply-chain event.

Mastra exposes a broader software governance debt in AI tooling ecosystems: AI agent frameworks concentrate many high-value integrations into one dependency tree, which makes compromised package distribution disproportionately dangerous. The more a package family sits near secrets, MCP tooling, and deployment surfaces, the more its release process becomes part of enterprise risk management. Practitioners should expect more attacks that target the ecosystem layer rather than the application source.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Registry metadata is now part of the software trust boundary: when a package family can be republished with a new dependency range, the visible source tree is no longer enough to establish trust. Build and release controls need to watch who published, how it was published, and what the registry resolved at install time. For security teams, that means dependency governance and identity governance now intersect at the package registry.

Semver carrier abuse is a distinct supply-chain pattern: the attacker does not need to change the obvious library logic if the resolver can be steered to a malicious patch release. That makes version ranges, install hooks, and package provenance the practical decision points for build security. Teams should assume the resolution layer is part of the attack surface.

AI agent frameworks intensify secrets exposure in build and developer environments: packages close to agent tooling, MCP integrations, and deployment surfaces are more likely to sit beside cloud credentials and service tokens. That raises the value of isolating build secrets and limiting what Node.js processes can see during dependency installation. AppSec and NHI governance should be designed together, not as separate reviews.

For practitioners

• Audit dependency ranges for semver-based carrier risk Review package.json, lockfiles, and published tarballs for dependency ranges that can resolve to newly added patch releases, especially where the dependency name resembles a benign or trusted package.
• Block or inspect install-time scripts in high-trust build paths Treat postinstall and similar hooks as execution events and require extra approval for packages that run code during installation on CI runners or developer workstations.
• Verify package provenance before accepting releases Check whether a package normally publishes from CI, whether the release came from an unexpected account, and whether registry metadata changed at the same time as the code.
• Reduce secret exposure on developer and runner hosts Limit access to cloud credentials, npm tokens, GitHub tokens, and AI provider keys in environments that install dependencies, because install-time code can harvest them directly.
• Rebuild compromised hosts from clean dependencies, not in-place edits If an affected package was installed, preserve logs and caches, then rebuild from a known-clean lockfile and rotate any secrets that were reachable from the host.

Key takeaways

• A one-line dependency change was enough to turn a trusted-looking npm package into an install-time execution path.
• The incident mattered because the affected environments often held cloud, GitHub, npm, and AI-provider secrets that the malicious code could reach.
• The control gap is not only code review but registry provenance, install-time script scrutiny, and secret exposure reduction on build hosts.

Key terms

• Semver Carrier Package: A semver carrier package is a dependency release that looks harmless at the top level but resolves to a malicious patch version underneath. It exploits normal version selection rules so a routine install can execute attacker-controlled code without an obvious source-code backdoor.
• Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
• Server Provenance: Server provenance is the evidence that an MCP server is known, approved, and trustworthy before an agent invokes it. It usually includes registry approval, signed artifacts, and verification of what version is running, which turns server selection into a governed trust decision.
• Build-Host Secret Exposure: Build-host secret exposure is the condition where CI runners or developer machines can access cloud tokens, API keys, or other credentials while installing or building software. It matters because a single compromised dependency can then pivot from code execution into credential theft and broader account abuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in the context of modern attack paths. It helps security, IAM, and AppSec teams connect identity controls to the systems that actually execute code and hold credentials.