Mastra npm Namespace Hit: 145 Packages Tampered After Contributor Account Hijack

Key points

• 145 npm packages under the @mastra/* namespace were tampered in a supply chain attack catalogued as easy-day-js.
• A single hijacked maintainer account with publish rights across the namespace was the entry point.
• Seven security vendors, including Endor Labs, JFrog and Socket, coordinated disclosure of the findings.
• CISA attestation requirements and SEC materiality rules both have direct bearing on affected organisations.
• Hardware-bound 2FA and OIDC-based trusted publishing would have materially reduced the risk.

What actually happened here?

Seven vendors, Endor Labs, JFrog, OX Security, SafeDep, Socket, StepSecurity and Snyk, jointly disclosed that 145 packages under the @mastra/* namespace were tampered as part of the easy-day-js campaign. The entry point wasn't a registry-side flaw. One npm maintainer account holding publish rights across the namespace was taken over, and the attacker used that access to push malicious versions of legitimate packages. We first reported the initial wave on 17 June, when the count stood at 144 packages; this coordinated disclosure adds vendor attribution and the final scope.

Mastra is used to wire up AI agents and inference pipelines. That makes the actual blast radius wider than raw download numbers suggest: compromised AI tooling can sit inside CI runners and inference services that hold model keys and customer data.

Should you worry about regulatory exposure?

Yes, if your organisation ships or procures federal software. Under CISA's Secure Software Development Attestation Form, federal software producers self-attest to controls covering trusted source code supply chains and MFA on developer accounts. A maintainer-account compromise on a widely depended-upon package cuts directly to those line items.

For SEC registrants, the question is materiality under Item 1.05 of Form 8-K, which requires disclosure of a material cybersecurity incident without unreasonable delay after that determination is made. A poisoned transitive dependency inside production AI infrastructure is the kind of fact pattern that forces a materiality call rather than excuses one.

Expect this incident to surface in SEC comment letters the next time an AI-forward registrant files a 10-K describing software supply chain risk factors. The pattern, single maintainer, broad namespace, AI tooling downstream, is precisely what examiners have been flagging.

What should your team do right now?

Pin and audit every @mastra/* version resolved during the compromise window. Rotate any secrets that touched build agents pulling those versions, and review npm token scopes. The npm registry security advisory feed is the authoritative source for version-level indicators as vendors coordinate removals.

Three controls would have blunted this: mandatory hardware-bound 2FA for publish operations; Trusted Publishing via OIDC from CI rather than long-lived npm tokens; and provenance attestations using npm's Sigstore-backed provenance, so consumers can verify a package was built from a specific commit in a specific workflow. None of those are novel. They're the floor that regulators and federal buyers increasingly expect.

The harder point is structural. Account takeover has been a persistent entry point across npm for months, our coverage since late May has tracked the Miasma campaign against Red Hat packages and a dual-intrusion delivering a kernel-level credential scraper. Easy-day-js fits the same pattern. One weak account. Enormous downstream reach. The registry's MFA enforcement posture is the variable that keeps coming up, and it's the one the industry hasn't settled.