AI & TechJune 24, 2026·6 min read

145 Mastra npm Packages Compromised via Hijacked Contributor Account

Mastra NPM Compromise: What Happened, Who’s At Risk, and How to Lock Down Your Supply Chain

Author: James Rowley (LinkedIn, GitHub)
Role: Principal DevSecOps Engineer, 15+ years in enterprise cloud and software supply chain security (Redacted Corp, EFF OSS Maintainer, SLSA Advisor)
Last updated: 2024-06-10 | Update log: [see below]
TL;DR: Multiple Mastra npm packages were compromised via a maintainer account takeover. If you use Mastra or depend on their packages, audit your dependencies, rotate secrets, enable 2FA, and review build logs for malicious behavior. npm Security Advisory | GitHub Advisory

Executive Summary

At least 145 npm packages under the Mastra scope published malicious updates after a maintainer account was hijacked (source: Snyk Advisory).
Attackers injected code to exfiltrate environment variables during install; downstream projects are at risk.
Immediate action: Audit Mastra dependencies, purge compromised packages, rotate all npm-related secrets, enable 2FA for all publishing accounts.

Mastra NPM Compromise: What Actually Happened

On June 6, 2024, Snyk and GitHub flagged at least 145 packages under the @mastra namespace as compromised (source). The attacker gained access to a maintainer’s npm account—likely due to weak credentials or no enforced two-factor authentication (2FA), a pattern seen before with similar registry breaches.

Malicious versions included install-time scripts that dumped environment variables and sent them to a remote endpoint. The payload targeted CI systems, local developer machines, and anything else running npm install. If you had Mastra in your dependency tree, there’s a nonzero chance your secrets were siphoned.

Who Is Affected?

Any project direct or transitive dependencies on @mastra npm packages released after June 6, 2024.
CI/CD platforms (GitHub Actions, Jenkins, GitLab CI, Azure Pipelines, etc.) invoking npm install as part of builds.
Docker images or serverless functions built with compromised versions.
Upstream maintainers who reference Mastra in their package.json, especially in model-serving, AI/ML ops, or performance tooling.

Technical Root Cause(s)

Account Takeover: Maintainer credentials compromised, likely via password reuse or lack of enforced 2FA (npm docs).
Weak CI Hygiene: Many pipelines (especially Jenkins and GitHub Actions using persisted npm tokens) lack granular publish scopes, relying on static credentials stored in secrets managers or environment variables.
Unverified Package Publishing: Upstream registries (npm) do not mandate cryptographic signing or provenance checks, making supply chain attacks easy to propagate (SLSA framework).
Open Source Overwork: Mastra maintainers reportedly lacked resources to monitor for unusual login behavior or review publish logs.

How to Detect Compromise: Indicators of Malicious NPM Packages

Red Flags:

Unexpected version bumps: Unexplained increase in package version number outside normal release cadence.
New install-time scripts: Presence of postinstall/preinstall scripts in recent package.json updates.
Obfuscated or minified code: Suspicious blobs in new releases, especially in scripts triggered during install.
Network calls during install: Build logs showing outbound HTTP requests during npm install.
Added or strange dependencies: Newly included packages unrelated to main function, often for data exfiltration.

How to Check:

Run npm audit — review output for Mastra-related vulnerabilities (npm audit docs).
Grep build logs for suspicious network activity (e.g., curl, fetch, HTTP endpoints).
Compare checksums (SHA256) of installed packages vs previous releases (npm docs).
Review install scripts in package.json for Mastra packages.
Use tools like Snyk and GitHub dependency review for cross-referencing advisory lists.

Immediate Mitigation Steps: Downstream Consumers and Maintainers

For Downstream Consumers

Pin dependencies: Lock Mastra and related packages to a safe pre-compromise version in package-lock.json.
Purge builds: Remove any artifact or Docker image built with compromised packages; initiate clean rebuilds.
Rotate secrets: Replace all npm tokens, environment secrets, and credentials exposed during builds after June 6 (npm token rotation docs).
Scan for malicious code: Use npm audit, Snyk, or Dependabot to identify vulnerabilities.
Isolate builds: Suspend or quarantine affected CI runners until clean environment confirmed.

For Maintainers

Revoke compromised npm tokens and reset passwords (npm token docs).
Enable 2FA for all publishing accounts (npm 2FA guide).
Publish sanitized package versions; increment version to signal remediation.
Notify npm support (contact npm) and downstream maintainers.
Submit advisory/CVE if malicious content was distributed (GitHub advisory process).
Review publish logs and IP addresses for unauthorized actions.

145 Mastra npm Packages Compromised via Hijacked Contributor Account

Harden Your CI/CD Publishing Credentials: Practical Controls & Config Snippets

Enforce OIDC for short-lived auth tokens in GitHub Actions

# GitHub Actions: requesting scoped npm publish token via OIDC
jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Authenticate to npm via OIDC
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          registry-url: 'https://registry.npmjs.org'
          always-auth: true
      - run: npm publish

Reference: OIDC for npm authentication

Enable npm token scopes & 2FA

Create tokens with minimal scopes (only for publish, no read/write all) (npm scopes reference).
Enforce mandatory 2FA for all npm accounts—set as required for publish actions (npm 2FA docs).

Build reproducibility

Use package-lock.json to pin package versions.
Generate and validate SBOMs with CycloneDX or SPDX — track dependencies for every build.
Deploy Sigstore/Cosign to digitally sign and verify packages in CI flows.

Long-Term Prevention Controls: Tighten Your Supply Chain

Move to private registries for sensitive packages (npm private registry guide).
Adopt SLSA Level 3 or higher for build provenance.
Periodically review and audit publish logs, contributor access, and package scripts.
Fund open source maintainers to incentivize operational security (OpenCollective, GitHub Sponsors).
Set up scheduled scans with Snyk, Dependabot, or comparable tooling.
Require SBOMs for all published artifacts—enforce at CI level.
Educate developers on dependency hygiene: don’t blindly update, review advisories weekly.

Quick Incident Response Checklist (Supply Chain Edition)

For Maintainers:

Revoke all npm publish tokens and reset credentials.
Enable 2FA and force password reset for all contributors.
Remove malicious package versions from npm; publish sanitized releases.
Inform npm, GitHub, and downstream users ASAP.
Issue public advisory/CVE (see GitHub process).
Conduct forensic review of publish logs, IP addresses, and package changes.
Submit findings to Snyk, npm, and OSS security mailing lists.

For Downstream Users:

Pin dependencies, update lockfiles to known-safe versions.
Rotate all exposed secrets and CI credentials.
Quarantine compromised build artifacts, images, and environments.
Audit dependency tree for Mastra or affected packages.
Use SBOM and reproducible builds to verify artifact integrity.
Report any suspicious findings to npm or relevant advisories.

Sources & Further Reading

Update Log

2024-06-10: Initial incident summary and practical mitigation steps
2024-06-11: Added specific IOCs, OIDC config snippet, and expanded advisories
2024-06-12: Section on open source maintainer safety and funding added

Maintainer Safety & Ethical Policy

Never publicly name or target individual maintainers. Most are overworked and unpaid. If you detect malicious code or security issues, report through npm’s official channels and coordinate advisories—not public callouts or threats. Support sustainability via projects like OpenCollective, GitHub Sponsors, or local foundations.

The Kicker

We treat open source as disposable infrastructure—until someone turns off the lights. Next time you run npm install, ask yourself: what’s hiding in that dependency tree, waiting for the inevitable lapse?

← More Articles