In just 88 minutes, a single npm account published more than 140 malicious versions of packages in the Mastra namespace. Mastra is a popular open-source JavaScript and TypeScript framework for building AI applications.
The infected packages themselves contained no malicious code. The attack was far more insidious. Each package's dependency list had been updated to include a third-party library named easy-day-js. That library was the real weapon.
The Mastra npm supply chain attack targeted one of the most sensitive environments in modern software development: AI infrastructure. Mastra packages are routinely installed in environments that hold cloud credentials, API keys, and sensitive business data.
The Attack Timeline
Quick Security Checklist
- Scan your system or website
- Update all dependencies
- Change passwords
- Enable 2FA
The campaign moved fast. The npm user "sergey2016" published easy-day-js as a clean, fully functional copy of the legitimate dayjs date library on June 16. Nothing was suspicious.
Early on June 17, the malicious changes were introduced to easy-day-js. After just a few minutes, the hijacked 'ehindero' account, who previously contributed to Mastra but didn't have their scope access denied, began to publish many 'malicious' versions of Mastra's packaged software.
Attacker's window was 88 minutes. The attacker used their own npm personal token and was able to get 'malicious' uploaded bypassing Mastra's normal trusted publisher flow.
How the Malware Works
The entry point of Mastra's npm supply chain attack is the easy-day-js package. Its postinstall hook executes a series of obfuscated scripts as a dropper/loader at installation time, which in turn execute the second stage script from an attacker-controlled server over a TLS connection by disabling the verification of the TLS certificates, thereby facilitating the exfiltration of the data without detection as a background process.
Afterward, the dropper/loader will delete itself to decrease the forensic evidence.
The final stage is a multi-platform information stealer that has the capability of:
1. Harvesting browser history
2. Stealing from 160+ cryptocurrency wallet browser extensions
3. Installing persistence on Windows, mac and Linux
4. Exfiltrating captured information back to the command and control server
Additionally, the malware can query the command and control server for commands, including downloading other modules from attacker-controlled URLs or executing them on the compromised system.
The Blast Radius
The affected packages include @mastra/core, which receives more than 918,000 weekly npm downloads. That gives the Mastra npm supply chain attack an enormous potential blast radius.
The payload executes during installation, not when the package is imported or used. That means systems may have been compromised simply by running npm install on a malicious version. No further action was required.
Any workstation, CI runner, or build environment that installed the affected versions should be treated as potentially compromised.
Why Mastra Was Targeted
Mastra sits at the intersection of AI development and cloud infrastructure. Its packages are installed in environments that hold some of the most sensitive credentials in modern software development.
AI frameworks often require access to cloud APIs, storage buckets, and databases. A compromised Mastra installation gives an attacker access to all of that, plus the ability to tamper with AI models and training data.
The attackers knew exactly what they were targeting.
Why Traditional Defenses Failed
The Mastra npm supply chain attack exploited multiple weaknesses in the npm ecosystem.
Weakness 1: Scope access was never revoked.
The hijacked account was from a legitimate, former contributor whose scope approval was not revoked, thus making the malicious packages appear as a legitimate package.
Weakness 2: No provenance requirement.
Mastra ships its real releases through npm's trusted publisher flow with SLSA provenance attestations. But the attacker pushed the malicious versions from a personal token and dropped the provenance. Mastra generated provenance on CI publishes but did not require it, so a standard npm token could still publish without attestations.
Weakness 3: Dependency confusion.
The infected packages added a dependency on easy-day-js. Since that package existed on npm, the installation succeeded. No one questioned why a Mastra package suddenly depended on a copy of dayjs.
What to Check and Do
If your organization uses any Mastra packages, take these steps immediately:
Check if you installed a malicious version.
Look at your package-lock.json or yarn.lock files. Check if any @mastra/* package was updated on or after June 17. The malicious versions include a dependency on easy-day-js.
Change all credentials.
Changed all credentials (for instance, the cloud APIs, DB credentials and any CI/CD pipelines that use tokens), as all of the credentials on a system that had an evil installation will have to be changed right away.
Audit infected systems.
The malware will maintain persistence and can download other modules. A basic scan is not sufficient; treat the host as a completely compromised machine.
Update to safe versions.
npm has pulled the malicious versions from the highest-profile packages and reverted their latest tag. Update to the latest safe version. But remember: updating removes the malicious dependency but does not clean a host that was already compromised.
Verify provenance going forward.
A signature-verifying install using npm audit signatures or a policy that requires attestations would have rejected every package in this wave. Implement these controls in your CI/CD pipelines.
A Small Dependency Change, Massive Impact
JFrog's analysis captures the sophistication of the Mastra npm supply chain attack: "The malware combined familiar supply chain techniques with practical stealth: a clean decoy version, an obfuscated postinstall loader, runtime payload download, detached execution, self-deletion, Node-themed persistence, and a remote module system."
Even if you remove the first-stage package after installation, the second-stage process may continue running and may have already installed persistence. This campaign shows how a small dependency change can become an install-time compromise across a large package ecosystem.
The Bottom Line
The Mastra npm supply chain attack is a textbook example of modern supply chain compromise. A hijacked account. A clean decoy package. A dependency added to 144 packages. A postinstall hook that drops a cross-platform stealer.
The attackers targeted AI infrastructure because it holds the most valuable credentials. They succeeded because the npm ecosystem still relies on trust rather than verification.
Check your package locks. Rotate your credentials. Audit your hosts. And treat every dependency as a potential entry point.
FAQ Section
What are the steps for identifying an installed non-original version?
You will want to check either the 'package-lock.json' or 'yarn.lock' file for any instance with the '@mastra/*' package updated either after June 17th of this year and check the entire package dependency tree to look for an entry with 'easy-day-js' as well.
What steps shall I follow when potentially having installed a non-original version?
Make sure you rotate any and all credentials saved on the affected instance as soon as possible, perform an audit on the instance looking for signs of compromise, and then update to the latest version of the Mastra package that is verified as safe.
What are the steps for identifying an installed non-original version?
You will want to check either the 'package-lock.json' or 'yarn.lock' file for any instance with the '@mastra/*' package updated either after June 17th of this year and check the entire package dependency tree to look for an entry with 'easy-day-js' as well.
What steps shall I follow when potentially having installed a non-original version?
Make sure you rotate any and all credentials saved on the affected instance as soon as possible, perform an audit on the instance looking for signs of compromise, and then update to the latest version of the Mastra package that is verified as safe.
Can I just update to fix the issue?
Updating removes the malicious dependency but does not clean a host that was already compromised. The malware may have installed persistence and additional payloads.
