Notifications
Clear all
Topic starter
02/08/2026 11:25 am
TL;DR: A supply chain attack republished 141 @mastra npm packages in a short window, added a malicious dependency, and used a postinstall hook to fetch a second-stage payload that targeted browser wallets and hid forensic traces, according to Aikido. The case shows how package trust, dependency resolution, and install-time execution can bypass conventional review and demand stronger software supply chain controls.
NHIMG editorial — based on content published by Aikido covering the Mastra npm supply chain attack: Over 140 popular Mastra npm packages hit by supply chain attack
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.
Questions worth separating out
Q: What breaks when npm package installs are allowed to execute code before inspection?
A: The control point disappears.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Aikido's analysis of the Mastra npm supply chain attack →
Mastra package supply chain attack: what did practitioners miss?
Explore further
02/08/2026 12:42 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Mastra npm packages hit by supply chain attack through malicious dependency
