Mastra Poisoned via npm Typosquat

On June 17, 2026, Sonatype researchers identified a supply chain attack targeting the Mastra AI framework. The attacker published a malicious npm package named easy-day-js, designed to mimic the popular dayjs library. When Mastra included this package as a dependency, its postinstall script executed, compromising the framework before any code review could detect it.

This attack wasn't a zero-day exploit or a complex network intrusion. The attacker simply published a package with a plausible name, waited for automated dependency resolution to take effect, and allowed the package manager to execute arbitrary code during installation.

Timeline

• Pre-attack: Attacker publishes easy-day-js to the npm registry with a postinstall script containing malicious payload.
• Unknown date: Mastra's dependency manifest is updated to include easy-day-js instead of dayjs.
• Installation phase: Developers and CI/CD systems run npm install. The postinstall script executes automatically with the same privileges as the installation process.
• June 17, 2026: Sonatype identifies the malicious package and campaign pattern.

The gap between compromise and detection remains unknown, meaning the malicious code could have run in development environments, build pipelines, and potentially production systems for an undetermined period.

Which Controls Failed

• Dependency verification: No cryptographic verification of package identity occurred. npm's package namespace allows anyone to publish easy-day-js if that exact name isn't taken, even though it clearly targets dayjs users.
• Manifest review: The dependency change didn't trigger a review workflow. Your package.json and lockfile changes should be scrutinized like application code.
• Script execution policy: The postinstall script ran without inspection or approval. Package managers execute these scripts by default, treating them as trusted code simply because they're in a package you installed.
• Build environment isolation: The installation process likely had access to credentials, network resources, or filesystem paths it didn't need. When postinstall scripts run with full developer or CI permissions, they can exfiltrate environment variables, SSH keys, cloud credentials, or source code.
• Dependency monitoring: No automated alerting fired when the dependency tree changed. If you're tracking commits but not lockfile modifications, you're missing the vector that matters.

What Standards Require

• PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software and third-party components. A package in your lockfile but not explicitly requested qualifies as an unreviewed third-party component.
• Requirement 6.4.3 requires protecting public-facing web applications from attacks. If your CI/CD pipeline can access production credentials, script execution controls apply.
• OWASP Top 10 2021: A06 - Vulnerable and Outdated Components addresses this risk. Transitive dependencies expand your attack surface without explicit approval.
• NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) requires configuration management and control throughout the system development lifecycle. A malicious package injection represents a security flaw introduced during development.
• ISO/IEC 27001:2022 Annex A.8.30 (Outsourced development) requires supervising and monitoring outsourced system development. Third-party npm packages qualify as outsourced development.

Lessons and Action Items

• Implement lockfile review as code review. Treat every package-lock.json or yarn.lock change as a material code change. Require approval from a security-focused reviewer before merging dependency updates. Use diff tools that highlight transitive dependency additions.
• Disable automatic script execution in CI. Set npm config set ignore-scripts true in your CI environment. For packages that need build scripts, maintain an allowlist and run those scripts in isolated containers with no credential access.
• Deploy a dependency firewall. Tools like Sonatype Nexus Repository or JFrog Artifactory let you proxy npm and vet packages before they reach your developers. Block packages published within the last 72 hours and those with suspicious names.
• Monitor your dependency tree, not just your manifest. Use npm ls --all to generate a complete dependency graph. Feed this into your SIEM or security monitoring platform. Alert on new packages, especially transitive dependencies without clear justification.
• Scope your build credentials. Run dependency installation in a separate job with no access to production secrets. Use ephemeral credentials with minimal scope for any external network access.
• Verify package signatures when available. Configure your package manager to reject unsigned packages from publishers who have previously signed their releases.
• Audit postinstall scripts in your current dependencies. Run npm explore <package> -- cat package.json for each dependency and check for postinstall, preinstall, and install scripts. Review their actions and evaluate the risk.

The Mastra incident highlights the growing threat of dependency hijacking in trusted package ecosystems. Until the ecosystem changes, you need to build verification and isolation into your processes. Your dependency manifest is executable code—review it accordingly.

CVE database