Skip to main content
144 Malicious npm Packages in 88 MinutesIncident
3 min readFor Security Engineers

144 Malicious npm Packages in 88 Minutes

What Happened

On June 17, 2026, an attacker compromised a contributor account in the Mastra namespace and published 144 malicious npm packages within 88 minutes. Each package included a dependency on 'easy-day-js', which installs a cryptocurrency-stealing trojan. Mastra is an AI and cloud infrastructure framework, so these packages likely infiltrated environments handling sensitive data and credentials.

The attack was successful because the compromised account retained publishing rights. The attacker executed a mass publication event, deploying malicious code across the entire namespace.

Timeline

Before June 17, 2026: A contributor account with publishing rights to the Mastra namespace was compromised. The method of compromise is not documented.

June 17, 2026 (88-minute window): The attacker published 144 packages, all introducing 'easy-day-js' as a dependency. The trojan targeted cryptocurrency wallets and credentials.

Post-publication: SafeDep and other security researchers identified the malicious packages. npm began takedown procedures.

The rapid execution—88 minutes for 144 packages—indicates the use of automation by the attacker.

Which Controls Failed or Were Missing

Access Lifecycle Management: The compromised account had unnecessary publishing rights. When a contributor's role changes or ends, their npm publishing tokens should be revoked immediately.

Anomaly Detection: Publishing 144 packages in 88 minutes is abnormal. No automated alert stopped the publication event.

Dependency Review: The introduction of 'easy-day-js' went undetected. None of the 144 packages had automated checks to flag a new, unvetted dependency.

Multi-Factor Authentication on Publishing: If the account required MFA for publishing, the attacker would have needed more than stolen credentials. The absence of this control allowed the credential compromise to escalate.

Pre-Publication Scanning: The packages were published without automated malware scanning or behavioral analysis. The trojan code was present, but no gate checked for it.

What the Relevant Standard Requires

NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) requires tracking and controlling software changes. For open-source maintainers, this means implementing controls to prevent unauthorized publishing. SA-10(1) calls for software integrity verification.

ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) addresses supply chain risk. You need technical controls over third-party code entering your build process, including verifying dependencies' integrity.

NIST Cybersecurity Framework (CSF) v2.0 SR.3.1 states: "The integrity of software is verified." For npm packages, this means validating that dependencies haven't been tampered with.

PCI DSS v4.0.1 Requirement 6.3.2 mandates custom code reviews before release to detect vulnerabilities. This logic extends to supply chain dependencies.

SOC 2 Type II CC6.8 requires monitoring vendor and third-party relationships. You need evidence that you're tracking what enters your dependency tree.

Lessons and Action Items for Your Team

Revoke Publishing Tokens Immediately: When contributors leave or change roles, revoke their npm tokens immediately. Implement a process where HR notifies the security team to revoke all publishing credentials.

Enable MFA for Publishing Operations: Configure your namespace so that publishing requires both a token and a time-based one-time password (TOTP).

Set Up Anomaly Detection for Package Publishing: Use tools like Socket, Snyk, or custom scripts to alert on unusual publication patterns. Real-time monitoring is essential.

Scan Dependencies Before They Enter Your Build: Use tools like npm audit, Semgrep, or SafeDep to analyze new dependencies before they're added to package.json.

Implement a Dependency Approval Process: For critical projects, require new dependencies to be approved by a security engineer before they're merged.

Use Lock Files and Verify Checksums: Ensure package-lock.json is committed to version control, and verify that downloaded packages match expected hashes.

Monitor for Dependency Changes in Pull Requests: Set up CI checks that flag any PR introducing a new dependency, providing context for reviewers.

The Mastra attack succeeded due to multiple absent controls. Implementing any of these actions—token revocation, MFA, anomaly detection, or dependency scanning—would have mitigated the impact. Adopting all of them strengthens your supply chain security.

Topics:Incident

You Might Also Like