Mastra npm Namespace Hit: 145 Packages Tampered After Contributor Account Hijack
Researchers tracking the 'easy-day-js' supply chain incident say a single compromised maintainer account was sufficient to push malicious versions across the @mastra/* registry footprint.
A coordinated disclosure from multiple supply chain security vendors places the scope of the npm intrusion at as many as 145 packages under the @mastra/* namespace, the registry home of the Mastra framework used to build AI agents in JavaScript and TypeScript.
The campaign has been catalogued as easy-day-js.
The entry point was not a registry-side vulnerability. It was an account takeover. A single npm maintainer account with publish rights across the namespace was compromised, and the attacker used that access to push tampered versions of legitimate packages to the public registry.
That distinction matters for downstream legal and disclosure analysis. Under CISA's Secure Software Development Attestation Form, federal software producers self-attest to controls covering trusted source code supply chains and multi-factor authentication on developer accounts. A maintainer-account compromise on a widely depended-upon package speaks directly to those attestation items.
It also intersects with the NIST SP 800-218 Secure Software Development Framework, specifically practice PS.1 on protecting code from unauthorized access and PS.2 on provenance.
The Mastra framework is used to wire up AI agents, tool calls and retrieval pipelines. That makes the blast radius wider than the raw download count suggests. Compromised AI tooling packages can sit inside developer machines, CI runners, and inference services holding model keys and customer data.
For SEC registrants, the relevant question is materiality under Item 1.05 of Form 8-K, which requires disclosure of a cybersecurity incident determined to be material without unreasonable delay after that determination. A poisoned transitive dependency in production AI infrastructure is the kind of fact pattern that forces a materiality call rather than excuses one.
Affected organizations should pin and audit @mastra/* versions 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 the vendor coordinates removals.
Several practical controls would have blunted this. Mandatory hardware-bound 2FA for publish operations. Trusted Publishing via OIDC from CI rather than long-lived npm tokens. 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 are, increasingly, the floor regulators and federal buyers expect.
Expect this incident to surface in comment letters the next time an AI-forward registrant files a 10-K describing its software supply chain risk factors. The pattern — single maintainer, broad namespace, AI tooling downstream — is exactly the scenario examiners have been telegraphing.
