144 Mastra npm packages compromised in supply chain attack via hijacked account

Mastra npm Packages Compromise: Details on the easy-day-js Supply Chain Attack

The Mastra npm packages compromise marks a scale of malicious activity rarely seen in JavaScript supply chains: 144 packages in the @mastra/* namespace, trusted by AI and JavaScript developers, were altered via a hijacked contributor account. The supply chain attack — codenamed easy-day-js — exposes how a single vulnerable credential can break the security chain for hundreds of downstream projects. Every developer who depends on an open-source framework owes it to themselves to study the patterns here: account security, package monitoring, detection, and faster incident response. There’s no antidote to awareness and action.

What happened in the Mastra npm packages compromise?

On June 17, 2026, security vendors JFrog, SafeDep, Socket, and StepSecurity reported a coordinated attack against the @mastra/* package namespace. The vector: a takeover of a single npm contributor account, ehindero. With that access, the attacker was able to mass-publish malicious updates to 144 individual npm packages associated with Mastra — a widely used open-source JavaScript and TypeScript framework for AI projects.

The compromised packages were released in bulk, exploiting the trust model npm enforces: contributor accounts govern package pushes, not immutable signatures or deterministic builds. The code name given to the attack, easy-day-js, encapsulates the speed and scale — hundreds of packages tainted in a matter of hours. JFrog identified the anomalous publication spike, with SafeDep, Socket, and StepSecurity independently verifying the affected package list and analyzing potentially malicious payloads introduced during the window.

For JavaScript and TypeScript teams, the immediacy of the impact is clear: any recent install or dependency update on @mastra/* packages could have fetched and run compromised code.

How does the easy-day-js supply chain attack work?

The easy-day-js compromise hinged on an npm account takeover, demonstrating the most direct, least-detectable vector in modern package ecosystems. Here’s how:

1. Account access: The attacker gained control over the legitimate ehindero npm account, a contributor to the @mastra/* namespace. Whether through credential phishing, weak password reuse, or misplaced tokens, the breach bypassed normal project governance and code review processes.
2. Mass package update: With push access, the attacker published new versions across 144 @mastra/* npm packages. This wasn’t a subtle or targeted insertion but a full-spectrum overwrite, maximizing potential reach.
3. Payload: While the source doesn’t specify the precise malicious payload, typical outcomes of these events include backdoors, credential stealers, dependency confusion vectors, or telemetry beacons. The hallmark is code that triggers upon package installation or runtime, often undetectable in transitive dependencies.
4. Attack surface: The @mastra/* namespace is used in artificial intelligence and JavaScript projects. Package managers and automation tools (CI/CD) that auto-update dependencies are especially exposed.

Supply chain attacks exploiting direct contributor access sidestep the usual perimeter controls — repository PR review, CI build checks — because npm treats a package as mutable by anyone with publish rights. The attack vector mirrors incidents seen elsewhere: everything is downstream of identity and access control. Once inside, the attacker doesn’t need to hunt for a vulnerability. The trust boundary is erased.

What risks does the Mastra package compromise pose to developers?

The fallout from the Mastra compromise runs deeper than a single malicious package. 144 libraries could potentially propagate:

• Arbitrary code execution: Malicious installation scripts (preinstall, postinstall) can trigger during npm install, running attacker-supplied code on developer machines, CI runners, or servers.
• Credential and data exfiltration: Exposed secrets, environment variables, or file system data can be targeted and sent to remote endpoints.
• Backdoors: Attackers may insert persistent code paths to grant ongoing access, observable only on close inspection.
• Malware distribution: Compromised npm packages can become vectors for spreading additional payloads through the downstream dependency tree.
• Supply chain amplification: Any open-source or AI project importing @mastra/* packages — directly or via dependencies — inherits the risk without direct code review.

Projects in rapid development cycles, automation-heavy CI/CD, or those that use wide-ranging dependency updates (i.e., ^ and ~ semver ranges) are acutely exposed. Any AI/JavaScript project installed or deployed during the compromised window is at risk. Granular access logs and runtime telemetry are often absent — by the time unusual behavior is observed, the damage is done.

How can developers identify if they are affected by Mastra npm package compromise?

Immediate steps for detection focus on dependency tracking, version auditing, and using automated tools.

1. Check @mastra/ usage:* Query your package.json, package-lock.json, or equivalent files for any @mastra/* imports. Be aware of transitive dependencies — tools like npm ls @mastra or yarn why @mastra can uncover indirect usage.
2. Inspect install history: Review dependency update logs and CI/CD runs around the reported breach date (2026-06-17). Newly installed or updated packages in this window should be considered suspect.
3. Compare package versions: Cross-reference installed @mastra/* versions against known safe releases. If you updated during the compromise period, assume exposure until versions are verified by security advisories.
4. Use automated scanners: Security vendors actively monitor high-profile breaches. Run tools like SafeDep, JFrog Xray, or Socket to flag known-compromised versions:

# SafeDep scan
npx safedep check .

# JFrog Xray example (assuming integration)
jfrog xr audit --watches=mastra-compromise

# Socket CLI
npx socket scan .

5. Monitor for advisories: Follow advisories and removal actions published by npm as compromised packages may be unpublished or deprecated post-incident.

Active package hygiene — and reviewing dependency resolution trees — is your strongest line of defense. Automated tools catch what manual review often misses.

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

Prevention is a process, not a patch. Developers and teams must reinforce both personal and organizational security controls:

1. Lock down contributor accounts: Enforce two-factor authentication (2FA) for all npm contributors. If your process mirrors Mastra’s, enable 2FA as non-optional and rotate credentials regularly.

# Enable npm 2FA on your account
npm profile enable-2fa auth-and-writes

2. Pin dependency versions: Avoid unbounded semver ranges in production workloads. Explicitly pin (1.2.3 not ^1.2.3) package versions to prevent surprise upgrades. Review all dependency changes through pull requests, not blind npm update.

{
  "dependencies": {
    "@mastra/core": "1.0.4" // pinned to known-good version
  }
}

3. Integrate automated monitoring and audit tools: Tools like SafeDep, JFrog Xray, and Socket should run as part of your CI pipeline. They can flag malicious code via heuristics, threat intel, or advisory lists before it reaches production.

4. Review and restrict contributor access: Regularly audit npm organization/team membership. Limit publish rights on sensitive namespaces to trusted, active contributors. Tie npm identities to strong, SSO-backed authentication.

5. Add a security.txt and incident contact mechanism: A visible security policy and contact reduces response latency when researchers identify issues.

6. Monitor package release events: Subscribe to automated monitoring of your package namespaces for new releases or anomalies. Treat mass publications as a trigger for immediate review.

7. Educate team members: Social engineering remains a top threat — train contributors to resist phishing, and ensure offboarding closes out ex-access holders swiftly.

Securing open-source projects is not just about code. It’s about process, education, and least-privilege access at every level.

What are the lessons from the easy-day-js incident for open source security?

The Mastra incident amplifies three realities of open-source dependence:

1. Account credentials are the supply chain root. It does not matter how strong your code review or CI discipline is if publishing credentials are weak. The trust anchor for every npm package is the account that holds publish rights.
2. Supply chain vigilance must be continuous. Mass updates in a short window, especially across established libraries, are almost always malicious. Real-time anomaly detection and incident drills aren’t optional for mature projects.
3. The ecosystem is interdependent and fragile. The actions (or lapses) of a single maintainer ripple outward to thousands of downstream applications. Security is both an individual and collective responsibility.

Open-source governance — from 2FA policies to documented incident protocols and fast advisory publication — must mature to match the importance of software in the modern stack. This is not just a Mastra problem or an npm problem. It is the normal state of the ecosystem.

Closing

The Mastra npm packages compromise isn’t an aberration — it’s the sort of event that defines a new security baseline for JavaScript and AI projects. 144 trusted modules were one breached credential away from turning every downstream application into an attack vector. Developers should treat this as a wake-up call: review every dependency, harden every contributor account, and make automated auditing a default. The threat landscape only gets wider — your response needs to be tighter.

For the next incident, make sure you’re upstream, not collateral.