More than 140 Mastra npm packages were republished with a malicious dependency named easy-day-js on June 17, 2026, turning a normal package install into a possible developer-workstation or CI-runner compromise. Security researchers at Socket, SafeDep, JFrog, Endor Labs, and StepSecurity all tied the incident to the Mastra AI framework ecosystem and warned that affected machines should be treated as exposed, not merely cleaned with a package downgrade.[1][2][3]
The attack matters because Mastra sits in the path of AI-agent, workflow, and retrieval-augmented generation projects. Those environments often hold LLM API keys, cloud credentials, GitHub or npm tokens, database secrets, and wallet data. Socket said the affected set included @mastra/core, a package with more than 918,000 weekly npm downloads, while Endor Labs described the broader Mastra package reach as more than 28 million downloads per month.[1][4]
The compromised Mastra packages did not need to contain the malware directly. Researchers found that the attacker added a single dependency line for easy-day-js, a lookalike of the legitimate dayjs date library. SafeDep reported that the clean-looking [email protected] was published on June 16, then [email protected] added a postinstall hook shortly after 01:00 UTC on June 17. Because the Mastra packages referenced ^1.11.21, fresh installs could resolve to the malicious newer release and run the payload during installation.[2][3]
What Mastra users should check now
Teams should first search repositories and lockfiles for easy-day-js and for affected @mastra/* versions installed during the June 16-17 exposure window. A simple package removal is not enough if the install already happened. JFrog and SafeDep both describe a loader that used npm lifecycle execution, downloaded a second stage, ran it in the background, and attempted to reduce forensic traces.[2][3]
Relevant indicators include npm accounts ehindero and sergey2016, package [email protected], the dependency pattern "easy-day-js": "^1.11.21", and the reported infrastructure 23.254.164[.]92 and 23.254.164[.]123. The exact remediation depends on where the package was installed, but the safer baseline is to isolate affected runners or workstations, rotate reachable credentials, revoke npm tokens, review GitHub and CI secrets, and check for persistence before returning systems to normal use.
This is also another reminder that software supply-chain incidents increasingly target build systems rather than only production servers. HowToFix.guide recently covered the Red Hat npm Miasma credential-stealing worm, the Mini Shai-Hulud npm and PyPI campaign, and the poisoned Nx Console extension that stole developer secrets. The Mastra case follows the same pattern: attackers look for a trusted developer path, then use install-time code or tooling trust to reach secrets before normal security controls notice.
For longer-term hardening, teams using npm should review whether package provenance is only present or actually enforced. SafeDep noted that legitimate Mastra releases used trusted publishing and SLSA provenance, but the malicious publishes came from a personal token and lacked those attestations. That means policies that reject missing provenance, verify registry signatures, delay newly published dependency versions, and block suspicious install scripts can reduce the blast radius of the next package-scope takeover.[2]
References
- Socket Research Team, “140+ Mastra npm Packages Compromised in Coordinated Supply Chain Attack,” June 17, 2026. socket.dev
- SafeDep, “Mastra npm Scope Takeover: 143 Packages Drop a RAT,” June 17, 2026. safedep.io
- JFrog Security Research, “easy-day-js: Supply Chain Campaign Targets Mastra npm Packages,” June 17, 2026. research.jfrog.com
- Endor Labs, “Mastra npm Org Compromised: Multiple Packages Trojanized to Drop a Remote Payload via easy-day-js,” updated June 17, 2026. endorlabs.com
- The Hacker News, “144 Mastra npm Packages Compromised via Hijacked Contributor Account,” June 17, 2026. thehackernews.com
Leave a Comment