144 Mastra npm packages compromised in supply chain attack

Mastra npm Packages Compromised: Inside the Easy-Day-JS Supply Chain Attack

The Mastra npm packages compromise is the largest targeted attack on an open-source JavaScript/TypeScript AI framework supply chain this year. Between June 16 and 17, 2026, attackers hijacked a single contributor account, flooding npm with 144 malicious package updates under the @mastra/* namespace. This "easy-day-js" campaign—uncovered independently by JFrog, SafeDep, Socket, and StepSecurity—exposed the central risk of weak account security in open-source. If you build with npm packages, especially in fast-moving AI stacks, this isn’t a hypothetical. These attacks target projects with real reach and real users. Locking down your dependencies, contributors, and review processes isn’t optional—it’s urgent.

What happened in the Mastra npm packages compromise?

At the core: a single contributor account (ehindero) was hijacked and used to publish 144 malicious package versions to npm under the @mastra/* namespace. Mastra powers AI workflows for JavaScript and TypeScript—making these packages building blocks for countless downstream apps and internal tools. Attackers leveraged the trusted permissions of this account to spread malicious code to every consumer pinned to @mastra modules. The campaign was systematic and fast: dozens of packages updated in a short window, leaving dependency graphs wide open.

The codename for this wave, “easy-day-js,” was assigned by the detection teams (JFrog, SafeDep, Socket, StepSecurity), reflecting the attack’s focus on easy injection through routine contributor access. In practice, npm’s default trust of maintainers meant that a single breach cascaded to all downstream apps that auto-updated, overrode lockfiles, or simply installed the affected packages after the compromise window began.

What made this noteworthy wasn’t just the volume (144 packages) but the speed and coordination. Incident trackers note an abrupt spike in publish activity tied to ehindero, followed by nearly simultaneous alerts across ecosystem security teams—proving that mature defenders can spot and attribute coordinated supply chain attacks within hours.

How does a software supply chain attack like easy-day-js work?

Software supply chain attacks exploit the trust placed in public package ecosystems like npm. Instead of attacking an application directly, attackers compromise a dependency—inserted deep in the graph and often maintained by volunteers. In this case: hijacking a legitimate contributor account (ehindero) and using it to push “routine” version bumps across dozens of Mastra packages.

Most modern dependency workflows assume that package updates from trusted accounts are benign. This is the exploit. When contributors can publish without multi-factor authentication (MFA), a single credential leak—or phishing, or token exposure—gives attackers the same access as the original maintainer. Package manager tooling (npm install, npm update) then fetches the latest versions, trusting the npm index.

What follows is an amplification loop: any project, anywhere, scripted or manual, that installs @mastra/* after the compromise window inherits the attack. The result is silent compromise at the build stage—only noticed if downstream teams aggressively audit hashes, monitor for suspicious activity, or if ecosystem defenders raise the alarm quickly. Unlike direct hacks, supply chain attacks hit thousands with a single upstream point of failure.

Takeaway: hijacked contributor accounts are the shortest path to mass compromise.

What risks do compromised Mastra npm packages pose to developers?

The risks aren’t theoretical. Compromised npm packages can introduce:

• Malware installation: Hidden payloads in post-install scripts or exported modules.
• Data exfiltration: Code that transmits disk, environment variable, or credentials data to attacker-controlled servers.
• Remote code execution (RCE): Hooks that let attackers run arbitrary code during npm install or on application startup.
• Persistence and lateral movement: Attackers seek to propagate from dev machines to CI/CD, production, or even pipeline credentials.

In the “easy-day-js” incident, the compromised packages could have enabled any of these attack types. Given Mastra’s positioning in AI data processing workflows, exfiltration of proprietary models, datasets, or secrets is a credible threat.

If you used npm install without a lockfile, or updated dependencies after the breach, you could have pulled in a malicious version automatically. Supply chain attacks are silent—unless your process detects unexpected version bumps, package size changes, or newly introduced scripts, you won't spot the breach until after the install.

Concrete threat scenario: an internal platform team uses Mastra as a core AI layer, triggers a CI build with npm ci or npm install, and unknowingly deploys code with backdoors or data leaks into production. Even isolated compromise of a developer laptop can escalate rapidly if secrets or deploy tokens are within reach.

How can developers identify if they are using compromised Mastra packages?

First, enumerate all direct and transitive dependencies on @mastra/*. Modern tools and shell commands help:

npm list @mastra/*        # list direct/transitive uses
yarn why @mastra/core     # explain why this package is present

Next, reconcile installed package versions against the official Mastra security advisory—refer to JFrog, SafeDep, or Socket for the list of affected versions. Look for any version installed after June 16, 2026, or those published by the ehindero account.

If you have strict lockfile management (package-lock.json or yarn.lock), review the locked version and publish date:

cat package-lock.json | grep mastra

For higher confidence, hash your installed packages and compare them against known-good (pre-compromise) hashes. This is slow but deterministic.

Review changelogs, commit SHAs, and npm publish metadata on the npm registry for evidence of unexpected ownership or abrupt mass updates. If a Mastra package updated without a corresponding, auditable release note or GitHub activity, treat it as suspect.

Tooling like SafeDep, npm audit, Socket, or custom dependency scanners can automate much of this. Incorporate these scans into your CI/CD and routine audits.

How to protect your projects from similar npm supply chain attacks today

No silver bullet, but concrete defenses reduce your risk.

1. Enforce MFA on contributor accounts: Require all maintainers and npm publisher accounts to use multi-factor authentication. Most attacks start with a password or token leak; MFA makes quick mass-compromises far harder.

2. Lock dependencies and validate updates: Pin your dependencies and review every version bump before merging. Relying on loose semver (^ and ~) invites silent upgrades to risky versions.

"dependencies": {
  "@mastra/core": "2.1.3"   // pinned, not auto-updating
}

3. Audit dependencies regularly: Use npm audit, yarn audit, SafeDep, or Socket to flag known-compromised packages or suspicious updates. Configure your CI to break builds for critical vulnerabilities.

npm audit --production

4. Prefer official and trusted registries: Avoid “shadow” or mirror registries that don’t enforce owner or MFA checks. Pull only from the official npm registry and monitor advisories.

5. Review contributor activity: Watch for sudden spikes in publish activity, contributor churn, or unexpected permission changes. When a formerly dormant account pushes dozens of updates, treat it as high-risk.

6. Harden your own publishing process: For libraries you maintain, use separate, locked-down publishing accounts, sign releases, and automate provenance checks.

There is no perfect defense. But combining these habits—MFA everywhere, dependency pinning and vetting, automated and manual audits—cuts your attack surface.

What are npm and the open-source ecosystem doing to prevent future attacks?

Ecosystem response moves at the pace of its largest failures. Following the Mastra breach:

• npm enforced stricter MFA policies. New and high-impact packages, including all AI frameworks, now require multi-factor authentication for all publishers.
• Community-led monitoring increased. JFrog, SafeDep, Socket, and StepSecurity coordinated real-time notification channels and mass dependency audits.
• Registry-side detection of mass-publishing behaviors. Npm is tuning for spikes from single accounts—multiple high-speed publishes now trigger internal review.
• Contributor vetting rises. Major maintainers are moving toward smaller, vetted teams with explicit owner rotation and transparent access logs.
• Best practices are codified. The after-action post-mortems distill the "known bad" patterns—lax MFA, open publish permissions, delayed notification—into advisories and automated rules.

The lesson is that ecosystem defense is collaborative—but reactive. Making use of new npm features (mandatory MFA, provenance, registry alerts) is essential, but so is project-side vigilance. Only by both locking your local supply chain and heeding upstream signals can you truly defend AI-driven codebases.

The takeaway: supply chain vigilance is non-optional

The Mastra npm supply chain attack—engineered through a single hijacked contributor account—proves the urgency of dependency hygiene for all developers, not just security teams. No one can rely solely on registry-level fixes; auditing dependencies, enforcing MFA, and monitoring for unexpected updates must be daily practice. The modern AI and JavaScript ecosystem moves at machine speed, but so do its risks. Secure your projects at the source and in the pipeline—your users, and your stack, depend on it.

For deeper dives: see npm supply chain attacks overview, securing open-source dependencies best practices, and how to audit npm package vulnerabilities.