Mastra npm packages hit by supply chain attack through malicious dependency

At a glance

What this is: A supply chain attack on the @mastra npm scope used a malicious dependency and install-time execution to deliver a wallet-targeting payload while hiding forensic traces.

Why it matters: It shows how AI framework ecosystems can be abused through dependency trust, making software supply chain controls relevant to teams that now deploy agents, plugins, and build dependencies together.

Context

The security gap here is not simply malicious code in a package, but the way package managers accept dependency changes and execute install hooks by default. When a published package can pull in a new version through caret resolution and trigger code during install, conventional review of the pinned package version is not enough.

This matters to identity and access teams because AI framework ecosystems increasingly sit beside browser extensions, credentials, and deployment tooling in the same delivery chain. Once a malicious package can reach install-time execution, it can cross from software supply chain risk into NHI exposure, secret theft, and session compromise.

The Mastra case is typical of modern package compromise patterns: attackers used the trust model of an open ecosystem rather than breaking the target codebase directly.

Key questions

Q: What breaks when a trusted package publishes a malicious preinstall hook into developer and CI workflows?

A: A trusted package can become an execution vector before users see any warning, because install-time hooks run automatically. In practice, this lets attackers steal SSH keys, cloud secrets, tokens, and configuration files from developer machines or build runners. The main failure is assuming package provenance alone protects the pipeline, when compromised publishing or CI can turn trust into silent execution.

Q: Why do malicious dependencies create such a wide blast radius?

A: They inherit the trust of whatever consumes them. A single compromised maintainer can affect many packages, and popular dependencies can be pulled into build systems, CI/CD runners, and production applications at high speed. That makes release authority and automatic adoption the main amplifiers of impact.

Q: What are the warning signs that a package compromise is executing at install time?

A: Look for unexpected postinstall scripts, downloads to temporary directories, detached child processes, and self-deleting launchers. Those patterns indicate the package is doing more than shipping library code and may be staging a payload outside normal package review.

Q: What should teams do when a package ecosystem worm is discovered?

A: Contain affected runners, revoke and rotate publishing tokens, freeze automated dependency updates, and review package ownership and release permissions before restoring pipelines. The priority is to stop credential reuse and republishing first, because that is what keeps the worm moving through the ecosystem.

Technical breakdown

How malicious dependency injection bypasses package review

The attack did not need to alter the main @mastra packages themselves. Instead, the attacker inserted a new dependency, easy-day-js, into package.json across the republished scope. Because npm accepts semver ranges such as ^1.11.21, a supposedly safe pinned line can still resolve to a later malicious release. That means the security boundary sits at dependency resolution, not only at source review. For practitioners, the real question is whether build and install policy controls can detect a malicious transitive dependency before it is trusted by the pipeline.

Practical implication: inspect transitive resolution behavior, not just top-level package versions.

Why postinstall hooks are a privileged execution path

npm postinstall hooks run automatically when a package is installed, which turns a supply chain compromise into immediate code execution. In this case, setup.cjs fetched a second-stage payload, wrote it to a temporary file, launched it as a detached process, and then removed itself. That sequence blends execution, persistence, and anti-forensics in one mechanism. For defenders, this is not a simple dependency hygiene problem; it is a runtime trust problem where installation itself becomes an execution event that needs policy enforcement and inspection.

Practical implication: treat install-time scripts as execution events and control them explicitly.

How second-stage payloads hide behind benign package behavior

The second stage in this attack was designed to look like an ordinary background process while actually collecting system information and targeting browser-based crypto wallet extensions. By spawning a detached process and self-deleting, the malware reduced the chance that a routine scan or manual review would catch it after installation. This is the same reason dependency compromise is so effective in modern development environments: the malicious behavior is deferred until after trust has already been granted. In identity terms, the package effectively borrowed the legitimacy of the installer and the developer workflow.

Practical implication: monitor for detached child processes and self-deleting installers in build and dev environments.

Threat narrative

Attacker objective: The attacker aimed to execute a concealed second-stage payload in trusted developer environments and reach browser wallets and other sensitive local assets.

1. Entry occurred when the attacker republished the @mastra npm scope and inserted the malicious easy-day-js dependency into 141 packages.
2. Credential and access abuse followed when npm caret resolution pulled the malicious 1.11.22 release into environments expecting the clean 1.11.21 version.
3. The postinstall hook fetched a second-stage payload, launched it as a detached process, and self-deleted to reduce forensic visibility.
4. Impact was malware execution inside developer and runtime environments, with the payload targeting browser-based wallet extensions and establishing long-lived background activity.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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

Software supply chain compromise is increasingly an identity problem as much as a code problem. When a package can inherit trust from the developer workflow and then execute during install, the attack is exploiting a delegated execution relationship, not just vulnerable code. That makes package provenance, script execution policy, and dependency approval part of identity governance for software delivery. Practitioners should treat install-time trust as a governed privilege boundary, not an operational convenience.

Install-time execution is the critical control gap this attack exposed. The package version that auditors would inspect was clean, while the malicious behavior appeared in the later release that semver resolution fetched automatically. This is a classic governance failure mode where the control model assumes the reviewed artifact is the one that will run. The practitioner lesson is that dependency policy has to govern the resolved artifact, not only the declared one.

Detached second-stage execution and self-deletion are hallmarks of supply chain tradecraft that compress dwell time. Once the payload runs outside the parent process and removes its own launcher, standard package review and basic endpoint checks lose visibility. That means software delivery pipelines need stronger runtime inspection and provenance controls, because the attacker is using the build and install path as an execution substrate. The control gap is persistence of trust after installation.

AI framework ecosystems raise the blast radius of package compromise because they sit close to secrets, browsers, and agents. The article’s package list spans agent tooling, browser components, cloud integrations, and observability modules, which shows how one compromised dependency can touch multiple governance domains at once. For identity teams, that is a warning that NHI exposure now extends into developer tooling and agent runtimes. The next control question is whether your programme can see and constrain package-driven privilege in those environments.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Supply chain compromise is now a privilege boundary issue for identity teams. When package resolution can silently swap a reviewed dependency for a malicious release, the control point moves from code review to trust governance over what is allowed to execute during install. That is why developer tooling, build runners, and agent runtimes now belong in the same risk conversation as secrets and session control.

Package ecosystems are becoming delivery vehicles for NHI exposure. In this case, the malicious payload targeted browser-based wallet extensions and ran inside trusted developer environments, which collapses the line between software supply chain security and identity protection. Teams should assume that a compromised package can now reach credentials, browser sessions, and agent-adjacent tooling in one chain of trust.

The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly, according to the State of Secrets Sprawl 2026. That pattern is relevant here because dependency compromise spreads laterally through trusted integrations faster than direct intrusion. Practitioners should plan for ecosystem-level exposure, not just isolated package remediation.

For practitioners

• Enforce dependency allowlisting for install-time execution Block or review packages that introduce new postinstall hooks, especially where semver ranges can pull in unreviewed releases at install time.
• Pin and verify resolved dependency versions Compare the resolved lockfile artifact against the version you intended to approve, and alert when a new transitive release appears under a trusted range.
• Scan build and dev endpoints for detached child processes Watch for package installation spawning background processes, temporary-file execution, or self-deleting scripts in developer workstations and CI runners.
• Separate browser-wallet and credential-bearing tooling from general build systems Keep extensions, secrets, and agent runtimes out of the same trust zone as routine package installs so one compromised dependency cannot reach everything at once.
• Trigger rescans after dependency-scope incidents When a package ecosystem compromise is detected, rescan affected repositories and connected endpoints immediately to identify whether the malicious version was resolved anywhere.

Key takeaways

• The Mastra case shows that package trust can fail at install time even when the inspected version looks clean.
• A malicious dependency plus an automatic postinstall hook is enough to turn software delivery into code execution.
• Teams need controls that govern resolved artifacts, install-time scripts, and the runtime processes they spawn.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Semver Resolution: Semver resolution is the mechanism a package manager uses to choose a version that satisfies a version range. Attackers abuse it by publishing a malicious release that still matches the expected range, allowing a trusted dependency to be swapped without changing the declared requirement.
• Second-Stage Payload: A second-stage payload is the later malicious component delivered after an initial foothold is established. The first stage usually acts as a loader or stager, while the second stage contains the main functionality, such as persistence, command execution, data theft, or remote control.
• Dependency Injection Attack: A dependency injection attack in the software supply chain inserts malicious code or a malicious package into a trusted dependency path. The target often believes it is installing ordinary library code, but the attacker is really using the dependency graph as a distribution channel.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to modern delivery and runtime risk.