On June 17, 2026, an attacker accessed a dormant npm account belonging to a former Mastra contributor. Within hours, they republished every package in the @mastra scope with a malicious dependency that disabled TLS verification and installed a cryptocurrency stealer. The core Mastra package alone receives roughly 4 million downloads a month.
This incident highlights a credential hygiene failure on a large scale.
What Happened
An attacker used a former contributor's npm account—credentials that should have been revoked when the contributor left the project. They republished the entire @mastra package scope, including a new dependency: easy-day-js.
The malicious package used a postinstall script to execute its payload. Once installed, it disabled TLS certificate verification and deployed a cryptocurrency wallet stealer. This attack exploited the npm registry's trust model: controlling a legitimate publisher account allows you to push any content to that scope.
Timeline
June 17, 2026: Malicious versions published across the @mastra scope
June 17, 2026 (hours later): Snyk detects the compromise and issues advisories
June 17-18, 2026: Organizations with lockfiles remain protected; those running npm install or npm update without lockfiles pull the malicious versions
June 18, 2026 onward: Remediation window opens as legitimate versions are restored
If your team ran npm install or updated dependencies without a lockfile during this period, audit your systems for the easy-day-js dependency and check for signs of TLS manipulation or unauthorized cryptocurrency transactions.
Which Controls Failed
Access revocation: The former contributor's npm account remained active with publish rights. Their credentials were not revoked when they left the project.
Multi-factor authentication: It's unclear if MFA was enabled, but the compromise suggests it wasn't, or the attacker bypassed it through session hijacking or credential stuffing.
Dependency pinning: Teams without lockfiles automatically pulled the latest versions. Those who ran npm update in CI/CD pipelines or local environments pulled malicious code without explicit approval.
Script execution controls: The postinstall script ran automatically during package installation, with no controls to prevent it from disabling TLS verification or installing additional binaries.
Anomaly detection: The sudden republishing of an entire package scope should have triggered alerts. Either npm's systems didn't flag this pattern, or the alerts didn't reach the right people quickly enough.
What the Standards Require
ISO/IEC 27001:2022 requires formal processes for granting and revoking access rights (Control 5.18). When a contributor leaves a project, their access should be revoked immediately, including npm publisher accounts and other systems with privileged credentials.
NIST 800-53 Rev 5 specifies automated mechanisms for disabling accounts after inactivity (AC-2(3)). If the account was dormant for months, automated controls should have flagged or disabled it.
PCI DSS v4.0.1 Requirement 8.2.6 mandates that inactive user accounts be removed or disabled within 90 days. While PCI DSS applies to cardholder data environments, the principle extends to any system where stale credentials create risk.
NIST Cybersecurity Framework (CSF) v2.0 includes identity and access management as a core function (PR.AA). Organizations should maintain an inventory of accounts with elevated privileges and review them regularly.
For the postinstall script execution, OWASP ASVS v4.0.3 Requirement 14.2.3 addresses the need to verify and validate all third-party components. Running arbitrary scripts during installation violates the principle of least privilege unless explicitly reviewed and approved.
Lessons and Action Items
Audit publisher accounts across all registries. Pull a list of everyone with publish rights to your organization's npm, PyPI, RubyGems, and Maven packages. Cross-reference against your current team roster. Revoke access for anyone who has left or changed roles.
Implement lockfiles everywhere. Your package-lock.json, yarn.lock, or pnpm-lock.yaml files should be committed to version control and enforced in CI/CD. Teams with lockfiles didn't automatically pull the malicious @mastra versions.
Disable postinstall scripts by default. Run npm install --ignore-scripts in your CI/CD pipeline. If specific scripts need to run, whitelist them explicitly. This won't stop all supply chain attacks but eliminates the automatic execution vector used by easy-day-js.
Set up registry change alerts. Configure monitoring that flags when packages you depend on publish new versions outside normal patterns. A sudden republish of an entire scope should trigger immediate investigation.
Require MFA for all publisher accounts. This should be non-negotiable. If npm supports hardware security keys (U2F/WebAuthn), use those instead of TOTP. They're resistant to phishing and credential stuffing.
Review your dependency update process. If you're running npm update automatically in CI/CD without human review, you're one compromised package away from deploying malicious code to production. Updates should go through the same review process as any other code change.
Check your systems now. If you installed or updated @mastra packages between June 17-18, 2026, search your dependency trees for easy-day-js. Check your TLS configuration for unexpected changes. Review cryptocurrency wallet activity on any systems that pulled the malicious versions.
The attacker didn't need to find a vulnerability in npm's infrastructure or exploit a zero-day. They just needed one forgotten password. Your credential hygiene determines whether that's a theoretical risk or your next incident report.
