Mastra npm packages hit by supply chain attack through malicious dependency

At a glance

What this is: Aikido reports a supply chain attack that republished 141 Mastra npm packages with a malicious dependency and install-time payload execution.

Why it matters: It matters because AI and software teams often rely on package trust and install-time automation, which can turn ordinary dependency updates into a non-human identity and supply chain exposure problem.

By the numbers:

• An attacker republished 141 packages in a burst between 01:15 and 02:00 UTC, silently injecting a malicious dependency into every one of them.
• The affected packages include @mastra/core, which has 918K weekly npm downloads, as well as mastra and create-mastra.
• The second stage targets over 160 browser-based crypto wallet extensions, including MetaMask, Keplr, Coinbase, and more.

👉 Read Aikido's analysis of the Mastra npm supply chain attack

Context

A package supply chain attack occurs when trusted software dependencies are altered to deliver malicious code downstream. In this case, the primary security problem is not just malware in a package, but the abuse of publishing trust, version resolution, and install-time execution inside the npm ecosystem. For AI agent frameworks, that matters because the software supply chain increasingly feeds automation, tool access, and runtime behavior.

The identity dimension is real even though this is not a classic IAM story. Package registries, build pipelines, and install hooks all depend on machine credentials, publishing rights, and trust relationships that behave like non-human identities. When those relationships are compromised, the resulting blast radius reaches developers, build systems, browser extensions, and downstream users in ways conventional appsec reviews often miss.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why do malicious dependencies create more risk than a simple package mismatch?

A: Because the danger is often in the execution path, not just the declared dependency tree. A package can arrive through a trusted channel, run install-time code, and access local secrets before scanners or approvals see anything unusual. That makes runtime behaviour the meaningful control point.

Q: What do security teams get wrong about package-lock files and npm audits?

A: They often assume a pinned version is enough, but dependency substitution can still change what gets installed or executed. Audits that focus only on the declared version miss install hooks, transitive additions, and republished lookalike packages. Teams need to verify resolved trees, script behavior, and publishing provenance together.

Q: Who is accountable when a supply chain package compromise reaches developer systems?

A: Accountability typically spans the engineering team that approved the dependency path, the platform team that defined install policy, and the security function that set provenance and monitoring requirements. Frameworks such as NIST CSF and MITRE ATT&CK help assign responsibility across prevention, detection, and response.

Technical breakdown

How malicious npm dependencies bypass package review

The attack pattern used here is a dependency substitution trick. The attacker first published a clean decoy version, then republished a malicious version that satisfied the same caret range, so consumers pulling ^1.11.21 received 1.11.22 automatically. That matters because many review processes inspect the pinned version or the top-level package, while dependency resolution happens later and can silently change what code is executed. In ecosystems like npm, the registry, versioning, and install behavior become part of the attack surface.

Practical implication: inspect resolved dependency trees and not just declared versions.

Why postinstall hooks are a high-risk execution path

npm postinstall hooks run automatically during installation, which makes them a powerful persistence and execution mechanism for attackers. In this case, the hook downloaded a second-stage payload, wrote it to a temporary file, spawned it as a detached process, and then deleted itself. That sequence reduces the chance that defenders see a long-lived malicious file on disk while still letting the code execute during a trusted software workflow. This is especially dangerous in CI and developer environments where installs happen repeatedly and often with elevated access.

Practical implication: treat install scripts as executable content that needs policy control.

How second-stage payloads extend impact beyond the package manager

The malicious payload did not stop at installation. It collected system information, targeted more than 160 browser wallet extensions, and disguised itself as node-related tools across operating systems to maintain persistence and evade casual inspection. That moves the incident from simple dependency tampering into downstream credential theft and environment compromise. For practitioners, the key lesson is that supply chain compromise often becomes an identity and secrets problem as soon as the payload can touch browsers, tokens, or developer endpoints.

Practical implication: monitor developer endpoints and browser-extension access as part of supply chain defence.

Threat narrative

Attacker objective: The attacker appears to have aimed to compromise developer and user environments at scale, then steal wallet-related credentials and preserve access through hidden background execution.

1. Entry occurred when the attacker republished 141 trusted npm packages with a malicious dependency that matched expected version ranges.
2. Escalation happened through an automatically executed postinstall hook that downloaded and spawned a hidden second-stage payload.
3. Impact came from persistence, system reconnaissance, and targeting of browser wallet extensions and other sensitive developer-side artifacts.

NHI Mgmt Group analysis

Package trust is becoming an identity problem, not just a code integrity problem. This attack worked because publishing authority, version resolution, and install-time execution were treated as trustworthy by default. In modern software delivery, those publishing rights function like non-human identities with privileged reach across build and developer environments. Practitioners should treat registry access, signing, and install execution as governance controls, not just engineering conveniences.

Dependency substitution is the new hidden blast-radius multiplier. The attacker did not need to compromise the top-level Mastra codebase to create downstream damage. By introducing a malicious dependency that fit an expected semver range, the attack turned routine upgrades into an execution vector. That pattern is increasingly relevant for AI and agent frameworks, where packages sit close to orchestration logic, tool access, and sensitive runtime context.

Supply chain defence now has to include developer-side secrets and browser surfaces. The second stage focused on browser wallet extensions and disguised persistence, which shows how quickly package compromise can become credential theft. That makes secrets exposure, session tokens, and local browser trust part of the same risk story as dependency hygiene. The right governance lens is not just package vetting, but control over what an install can reach once execution begins.

AI framework ecosystems amplify trust concentration. Open-source agent frameworks often pull together many plugins, auth adapters, storage connectors, and runtime integrations. That makes the ecosystem structurally attractive for attackers because a single scope compromise can reach many downstream environments at once. The practical conclusion is that AI platform teams need stronger software supply chain controls before framework sprawl becomes a standing exposure.

Install-time execution needs policy, not hope. Postinstall hooks are convenient for developers but dangerous when package provenance is weak. When automation can run code before human review, the organisation inherits the attacker’s timing. Security teams should move toward explicit approval, sandboxing, and provenance validation for package installation decisions.

What this signals

Developer supply chains now sit inside the identity perimeter. When install hooks can execute code and browser extensions can be targeted, the boundary between application security and identity governance collapses into a single control problem. Teams should review whether package approval, secrets exposure, and endpoint monitoring are managed together or left in separate operational silos.

Secret exposure windows matter more when malicious code is designed to disappear. The article’s self-deleting payload pattern shows why incident response cannot rely on static file inspection alone. Pair provenance validation with runtime monitoring and the OWASP Non-Human Identity Top 10 to reduce the chance that a compromised dependency becomes a credential or token event.

Dependency governance is becoming an AI governance issue. AI agent frameworks concentrate trust in packages, connectors, and toolchains, which means supply chain compromise can influence model-adjacent execution paths as well as ordinary software builds. Organisations should align software supply chain controls with the NIST AI Risk Management Framework before agent frameworks become a repeatable attack surface.

For practitioners

• Constrain install-script execution by policy Block or sandbox npm postinstall behavior in CI, build images, and high-risk developer environments unless the package is explicitly trusted and reviewed.
• Verify resolved dependency trees, not just pinned versions Inspect the fully resolved lockfile and transitive dependency graph so caret range abuse and malicious version swaps are visible before deployment.
• Monitor developer endpoints for wallet and token exposure Add detection for browser extension access, unusual node-like persistence, and temporary-file execution patterns on developer machines and build hosts.
• Require provenance checks for package publishing and install Use registry controls, signed artifacts, and allowlists for packages that can reach sensitive build or runtime environments.

Key takeaways

• This incident shows that package trust, not just source code, is a live attack surface in AI and developer ecosystems.
• Scale matters here because 141 packages, 918K weekly downloads, and install-time execution created a wide and fast-moving exposure path.
• Controls that verify resolved dependencies, restrict install scripts, and watch developer endpoints would have reduced the attacker’s room to operate.

Key terms

• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
• 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.
• Dependency Substitution: Dependency substitution is the abuse of package versioning so a benign or expected dependency is replaced by a malicious one that still satisfies install requirements. It works because many build systems trust semver resolution more than they validate the actual code path being pulled in.
• Developer Endpoint Risk: Developer endpoint risk is the elevated exposure created when a workstation holds source code, signing material, tokens, and access to build or repository systems. A compromise can propagate beyond the device because the attacker can reuse those identities and trust relationships elsewhere.

What's in the full analysis

Aikido's full blog covers the operational detail this post intentionally leaves for the source:

• The exact malware logic in the postinstall hook, including how the second-stage payload is fetched and executed.
• The full list of affected Mastra package versions and the republishing sequence across the npm scope.
• The indicators of compromise for the first-stage and second-stage infrastructure.
• Aikido's detection and rescan guidance for teams that need to verify exposure quickly.

👉 The full Aikido post covers the attack chain, affected packages, and indicators of compromise.

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 helps security practitioners connect identity controls to the broader operational risks that show up in modern software supply chains.