# 144 Mastra npm Packages Compromised in Major Supply Chain Attack Targeting AI Developer Ecosystem


A sophisticated software supply chain attack has compromised at least 144 packages in the Mastra namespace on npm, exposing thousands of developers who rely on the popular open-source framework for building artificial intelligence applications. Researchers from JFrog, SafeDep, Socket, and StepSecurity identified the campaign, codenamed easy-day-js, which exploited a single hijacked contributor account to inject malicious code across a sprawling dependency tree.


The attack represents one of the most significant npm namespace compromises to date, leveraging the trust developers place in established open-source projects to distribute what researchers describe as "sophisticated backdoor capabilities" across the JavaScript and TypeScript ecosystem.


## The Attack: How It Unfolded


On or around mid-June 2026, an attacker gained control of the npm account ehindero, which maintained elevated privileges across the Mastra namespace. Rather than targeting a single high-profile package, the threat actor used this access to mass-publish malicious versions across the entire ecosystem of @mastra/* packages simultaneously.


Key timeline details:

  • Attacker account takeover: Date unconfirmed, but malicious packages appeared around June 2026
  • Discovery: Identified by security researchers across multiple firms conducting supply chain monitoring
  • Scope: At least 144 packages published with compromised code
  • Detection lag: Initial delay before community notification, with some installations occurring before detection

    • The simultaneity of the releases—across dozens of packages in rapid succession—suggests either automated tooling or deep familiarity with the Mastra publishing workflows. This pattern differs from traditional account compromises, which typically show exploratory or scattered activity before large-scale exploitation.


    ## Background: Understanding Mastra and Its Position in the AI Stack


    Mastra is a modern framework designed to simplify the development of AI applications using JavaScript and TypeScript. It abstracts away infrastructure complexity, allowing developers to build, test, and deploy AI agents and workflows with minimal boilerplate code.


    Why Mastra matters:

  • Growing adoption: The framework has gained traction among AI developers building production agents, RAG (Retrieval-Augmented Generation) systems, and autonomous workflows
  • Dependency reach: As a foundational framework, Mastra packages are pulled into numerous downstream projects, multiplying exposure
  • Trusted position: Mastra benefits from the credibility of open-source infrastructure—developers often have relaxed scrutiny for established project updates
  • Integration with sensitive systems: Mastra applications frequently interact with API keys, database credentials, and external service integrations

    • The namespace's apparent maturity and position in the AI development ecosystem made it an attractive target for supply chain attackers seeking broad distribution with minimal friction.


    ## Technical Details: What the Malicious Code Does


    Researchers have identified several concerning capabilities injected into the compromised packages:


    Reported malicious behaviors:

  • Credential exfiltration: Code designed to harvest environment variables, API keys, and authentication tokens from infected build environments
  • Dependency manipulation: Modifications to package.json or build scripts to inject additional malicious packages
  • Data exfiltration: Capabilities to transmit sensitive data to attacker-controlled command-and-control infrastructure
  • Supply chain persistence: Mechanisms to embed malicious code in downstream projects, extending compromise beyond direct consumers

    • The sophistication of the payload suggests attackers understood the typical deployment patterns of Mastra applications—particularly their interaction with cloud services, LLM APIs, and persistent data stores.


    One critical factor: the attack leveraged npm's trusted update mechanism. Developers running standard dependency update commands or CI/CD pipelines that automatically pull the latest minor/patch versions would have unknowingly installed malicious code without additional warnings or review steps.


    ## Scope and Impact: Who Is Exposed


    Exposure analysis:

  • Direct consumers: Any developer or organization with @mastra/* packages in their dependency tree installed between the compromise date and removal
  • Build artifacts: Applications compiled and deployed using compromised versions may contain injected backdoor code
  • Transitive dependencies: Downstream projects depending on affected applications inherit the compromise
  • CI/CD systems: Build environments where these packages were installed may have had credentials exfiltrated

    • The distributed nature of npm means infection counts will be difficult to quantify precisely. Security researchers typically estimate download and installation numbers using npm registry statistics, but actual exploitation depends on whether attackers successfully extracted credentials or code from infected systems.


    Notably, organizations using npm audit or similar tooling may not have detected the compromise immediately, depending on when security advisories were published and when scanning occurred.


    ## Detection and Response Timeline


    Community response sequence:

    1. Research discovery: JFrog, SafeDep, Socket, and StepSecurity independently or collaboratively identified suspicious patterns

    2. Advisory publication: Security advisories and CVEs published (specific CVE numbers pending at time of reporting)

    3. Package removal: npm removed malicious versions from the registry

    4. Yank process: Affected packages marked as "yanked" to prevent new installations, though existing lockfiles may reference compromised versions

    5. Developer notification: Ecosystem alerts and security mailing list notifications issued


    What developers need to check:

  • npm audit output and security advisories
  • package-lock.json or yarn.lock files for compromised versions
  • npm registry history for their projects
  • Build logs and CI/CD histories for suspicious activity during affected timeframe
  • Environment variable exposure or unexpected API activity during the compromise window

    • ## Implications for the JavaScript and AI Development Community


    This attack exposes fundamental vulnerabilities in npm's security model:


    Structural weaknesses highlighted:

  • Single account as a choke point: One compromised credential can poison an entire namespace
  • Lack of mandatory code review: Unlike some ecosystems, npm packages can be published without peer review or automated security scanning
  • Limited namespace controls: Namespace maintainers lack granular permission controls that could limit blast radius
  • Silent installation model: Updates install automatically in many workflows without explicit developer approval

    • For AI development teams specifically, this is particularly concerning because Mastra applications frequently interface with sensitive external systems—LLM APIs, cloud infrastructure, and enterprise databases—making exfiltrated credentials immediately actionable.


    ## Recommendations for Developers and Organizations


    Immediate actions:

  • Audit package-lock.json and yarn.lock files for any @mastra/* packages installed during the affected period
  • Run npm audit and review any advisories related to Mastra
  • Rotate any API keys, credentials, or secrets that may have been exposed or used in environments where compromised packages ran
  • Check CI/CD logs and build artifacts for suspicious activity or unexpected network requests

    • Medium-term hardening:

  • Implement lockfile auditing in CI/CD pipelines to detect unexpected changes
  • Use npm workspaces or monorepo tooling to isolate and control dependency updates
  • Adopt software composition analysis (SCA) tools that monitor not just versions but code changes across updates
  • Consider code signing verification for critical dependencies, where available
  • Require explicit approval for dependency updates rather than automatic installation

    • Ecosystem-level improvements:

  • npm should implement mandatory two-factor authentication (2FA) for namespace maintainers
  • Introduce per-package publish controls and approval workflows
  • Enable automated anomaly detection for publishing patterns (e.g., mass releases across many packages)
  • Support namespace-level signing to cryptographically verify package authenticity

    • ---


    ## HackWire Analysis


    The Mastra compromise is emblematic of a broader trend in software supply chain attacks: the shift toward horizontal exploits. Rather than targeting a single high-value package, attackers are increasingly hijacking namespace-level access to maximize reach and minimize per-package scrutiny.


    What's particularly concerning is the timing. The AI application ecosystem is experiencing explosive growth, with frameworks like Mastra becoming standard infrastructure for new AI workflows. Developers building in this space are often moving fast, prioritizing functionality over security, and frequently spinning up AI agents with broad API access. An attacker injecting credential-stealing code into widely-used AI infrastructure catches developers at their most vulnerable—the moment when they're least likely to have visibility into what their dependencies are actually doing.


    The sophistication also suggests this wasn't opportunistic. The ease-day-js campaign appears to be the work of an organized threat actor with understanding of npm distribution mechanics and knowledge of Mastra's ecosystem positioning. This isn't a script kiddie defacing packages; it's a calculated move to gain foothold access across a high-value, rapidly-growing developer cohort.


    The real lesson: the npm ecosystem has outgrown its original trust model. The registry was designed assuming that package maintainers were essentially trustworthy—account security was the responsibility of individual developers. That assumption breaks down at scale. With hundreds of thousands of packages and millions of daily installs, the system now needs mandatory verification, namespace-level controls, and anomaly detection that matches the sophistication of the attackers exploiting it.


    For defenders, this is a reminder that "from a trusted open-source project" is not a sufficient security criterion. Mastra has a legitimate reputation, but that reputation is orthogonal to whether any given version actually contains what you think it contains. Until npm implements cryptographic verification and per-package code signing, developers need to treat dependency updates as security events—not routine maintenance. — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Tools](https://www.hackwire.news/category/tools) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)