Dateline: June 18, 2026
The Supply Chain Hack That Hit AI Developers
Attackers did not need to crack Mastra’s code to break into thousands of developer machines. They needed one forgotten account. On June 17, 2026, a single hijacked npm login pushed malware into 144 packages tied to the Mastra AI framework, and most developers had no idea until it was over.
What Happened?
Mastra is a popular open-source framework for building AI apps in JavaScript and TypeScript. Its packages get pulled into projects that hold some of the most sensitive secrets in software work, things like LLM API keys, cloud credentials, and CI/CD tokens.
The attacker got in through “ehindero,” a former Mastra contributor whose publishing access was never removed. With that account, they ran an automated campaign that republished 144 packages across the @mastra scope in an 88-minute window. The packages themselves looked clean. The trick lived one level down.
Each package got a new dependency called easy-day-js, a fake copy of the well-known dayjs date library. The attacker even published a working, harmless version a day earlier to build trust, then swapped in the malicious code minutes before the mass publish. easy-day-js copied dayjs’s author name, homepage, and license word for word to survive a quick review.
Once installed, easy-day-js fired an obfuscated postinstall script. That script turned off TLS checks, pulled a second-stage payload from attacker servers, ran it as a hidden background process, then deleted itself to cover its tracks. The payload was a cross-platform info-stealer. It went after browser data from Chrome, Edge, and Brave, raided more than 160 cryptocurrency wallet extensions, and set up persistence on Windows, macOS, and Linux before sending everything back to its operators.
Here is the scary part. Running npm install was enough. No need to import the package or write a single line of code.
What’s the Impact?
@mastra/core alone pulls in over 918,000 weekly downloads, so the blast radius was huge. Any workstation, CI runner, or build server that installed an affected version after June 16 should be treated as compromised.
For AI teams, the stakes climb higher. Stolen LLM API keys and cloud credentials can expose model endpoints, data pipelines, and production systems far beyond the machine that got hit. Individual developers faced direct financial risk too, with crypto wallets in the crosshairs.
What stings most is how avoidable it was. npm does not expire publishing rights when a contributor goes quiet, so one stale credential opened the door to an entire package namespace.
How to Avoid This
- Run npm ls easy-day-js across your projects to spot the bad dependency fast.
- Roll back to a known-clean version with verified provenance, then rotate every credential the host could touch, including npm tokens, cloud keys, and API keys.
- Pin your lockfiles and turn on cooldown periods so brand-new package versions cannot land in your build the second they publish.
- Block install-time scripts by default and treat postinstall hooks as an attack surface, not a convenience.
- Review contributor access on your own projects and pull permissions the moment someone steps away.
Beyond the Patch: Where Supply Chain Defense Actually Holds
Code review never catches a clean-looking package with a poisoned dependency buried underneath. Secure.com gives security and AppSec teams the visibility to catch what slips past manual checks.
- Map every dependency in your build, including the ones pulled in indirectly, so nothing hides one level down.
- Flag risky package behavior like install-time scripts and disabled TLS before they run in your pipeline.
- Catch stolen or exposed credentials early, so a compromised key does not turn into a full breach.
- Watch contributor and token access across your repos and surface stale permissions that should have been revoked.
- Tie alerts to real context, so your team chases the threats that matter instead of drowning in noise.
