Mastra npm Scope Takeover: AI Framework Supply Chain Backdoored

Key Takeaways

• On June 17, 2026, an attacker used a hijacked former-contributor account to republish approximately 144 packages across the entire @mastra npm scope, injecting a masquerading dependency that delivered a cross-platform remote access trojan and cryptocurrency stealer.
• The malicious package—easy-day-js—mimicked the legitimate dayjs library in version numbering and metadata, exploiting npm’s semver resolution to automatically pull a weaponized update onto systems that had already installed what appeared to be a clean dependency.
• The root cause was not a zero-day vulnerability but a governance failure: a former contributor’s account retained publish rights to the entire scope long after their involvement ended, and npm provides no automatic mechanism to expire stale access.
• Any developer workstation, CI/CD pipeline, or build server that ran npm install for any @mastra/* package between June 17, 2026 (01:12 UTC) and approximately June 17, 2026 (18:00 UTC, when remediated versions were broadly available) should be treated as potentially compromised, and all associated credentials—including LLM API keys—must be rotated immediately.

Background

Mastra is a TypeScript framework for building AI agents and AI-powered applications. Created by the team behind the Gatsby web framework and headquartered in San Francisco, Mastra launched in 2025 and quickly became a significant tool in the agentic AI developer ecosystem [1]. The framework provides primitives for constructing AI agents, multi-step workflows, retrieval-augmented generation pipelines, and persistent memory systems, with routing support for more than ninety model providers including OpenAI and Anthropic. Its flagship package, @mastra/core, recorded approximately 918,000 weekly downloads in the week preceding the attack, with the broader @mastra scope exceeding 1.1 million combined weekly downloads [2].

This adoption profile made Mastra an attractive supply chain target. Because Mastra requires LLM API keys to route requests to providers such as OpenAI and Anthropic, developer environments running the framework commonly hold sensitive credentials—cloud provider tokens, database connection strings, and deployment secrets—precisely the class of material that a supply chain attacker seeks to exfiltrate. When a package of this reach can be weaponized without touching its source code or repository, the attack surface expands to every downstream developer and automated pipeline running npm install.

The incident illustrates a recurring pattern in npm supply chain attacks—combining credential compromise with dependency injection—that security researchers have documented with increasing frequency [14]. These operations have progressed beyond simple package-name imitation toward more complex techniques targeting maintainer credentials and scope-level publishing rights [14]. The Mastra attack combined multiple such techniques—credential hijacking, a credible bait package, semver exploitation, and a self-deleting dropper—in a single coordinated campaign that was executed and largely complete within 88 minutes of initial payload delivery [3][4].

Security Analysis

Attack Mechanics

The operation unfolded across two days, structured to maximize credibility before weaponization. On June 16, 2026 at 07:05 UTC, a newly created npm account (sergey2016, associated with [email protected]) published [email protected]—a clean, fully functional copy of the popular dayjs date manipulation library [3]. The package mirrored dayjs’s version numbering, reproduced the original author metadata (including the iamkun author field), copied the repository URL, homepage, and keywords, and contained no malicious code whatsoever. Its sole purpose was credibility: to appear in the npm registry as a legitimate, established library so that any early-detection system reviewing package metadata would find nothing actionable.

Approximately eighteen hours later, at 01:01 UTC on June 17, the attacker published [email protected] containing a weaponized setup.cjs postinstall hook. The version increment from 1.11.21 to 1.11.22 was the critical operational step. Any project with easy-day-js pinned under a caret range ("^1.11.21") would have npm’s semver resolution automatically select version 1.11.22 on the next install—no explicit action required from the victim [4].

The actual package injection began at 01:12 UTC and concluded at 02:39 UTC, an 88-minute automated campaign in which the hijacked ehindero maintainer account republished approximately 144 packages across the @mastra npm scope, each updated to include easy-day-js as a dependency [2][3]. (Source reports vary slightly on the total, citing figures between 141 and 145 [10][13]; this document uses the figure most consistently supported across primary technical analyses.) The ehindero account belonged to a former Mastra contributor whose publishing rights had never been revoked after their involvement in the project ended in early 2025. Evidence of the takeover includes a change of the account’s associated email address to [email protected], consistent with the attacker’s operational email domain [5].

The use of a compromised legitimate account rather than a newly created one appears deliberate: a fresh account would have lacked scope publish access and triggered npm’s new-maintainer review heuristics. Microsoft’s threat intelligence team, which detected the anomalous publishing activity, found no evidence attributing the campaign to a previously named threat group [6].

Payload Behavior and Capabilities

The setup.cjs dropper embedded in [email protected] is 4,572 bytes and employs three distinct obfuscation layers: custom-alphabet Base64 encoding, array rotation with integrity checksums, and XOR-encoded beacon markers [3]. When npm install triggers the postinstall hook, the dropper performs the following sequence of operations.

First, it sets the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0', disabling TLS certificate validation for all subsequent network calls within the same process. This allows the dropper to communicate with attacker-controlled infrastructure using a self-signed certificate without generating a connection error. Second, it writes beacon marker files—.pkg_history and .pkg_logs—to the system’s temporary directory, recording that a given machine has been successfully reached and preventing duplicate execution. Third, it fetches a Node.js second-stage implant from https://23.254.164.92:8000/update/49890878, the primary command-and-control (C2) server [3][6]. Fourth, it spawns the downloaded implant as a detached background process using Node.js’s child_process.spawn with the detached flag, decoupling the payload’s lifecycle from the npm install process. Finally, it deletes the setup.cjs file from disk to remove forensic evidence of stage one.

The second-stage implant is a cross-platform remote access trojan and credential harvester. On Windows, it achieves fileless code execution through reflective .NET assembly injection, reducing the forensic footprint on disk [6]. Across Windows, macOS, and Linux, the implant establishes persistence through platform-native mechanisms: Registry Run keys on Windows, LaunchAgent property lists on macOS, and systemd service units on Linux. The payload inventories browser extension installations across 166 identified cryptocurrency wallet browser extensions [6], exfiltrates browser history, and profiles the host environment—including installed applications, operating system details, and available environment variables [2][4]. The last category is particularly significant for AI developer environments, where environment variables routinely hold LLM API keys, cloud provider credentials, and CI/CD tokens. The implant communicates with a secondary C2 server at 23.254.164.123 on port 443 for persistent operator command and control [3].

Indicators of Compromise

Organizations assessing potential exposure should search for the following indicators. At the network layer, any outbound connection to 23.254.164.92 (port 8000) or 23.254.164.123 (port 443) from a development host or CI runner during or after June 17, 2026 is a high-confidence indicator of compromise. At the filesystem layer, the presence of .pkg_history or .pkg_logs in the system’s temporary directory (/tmp on Unix-like systems, %TEMP% on Windows) indicates that the dropper executed successfully. Package managers’ lock files can be examined for explicit references to [email protected]; the presence of this version in any lock file confirms the malicious dependency was resolved. The attacker accounts involved are sergey2016 (publisher of easy-day-js) and ehindero (the compromised Mastra scope maintainer), both now deactivated on npm. Kodem Security has published a detailed IOC and response runbook [11] that organizations can use as a reference during incident response triage.

Recommendations

Immediate Actions

Any organization that installed @mastra/* packages, the top-level mastra package, or create-mastra between June 17, 2026 (01:12 UTC) and approximately June 17, 2026 (18:00 UTC, when remediated package versions were broadly available) should treat the affected environment as compromised and initiate incident response procedures. The scope of potentially affected versions spans [email protected] [5] and all @mastra/* packages published in that window. Remediated packages have been forward-rolled by the Mastra team and are now available; updating to the latest published versions removes the malicious dependency going forward, but does not address a compromise that has already occurred.

Credential rotation is mandatory for any environment that may have installed affected packages. This includes LLM API keys for providers such as OpenAI, Anthropic, and Google; cloud provider access keys and service account credentials; npm and GitHub tokens; CI/CD pipeline secrets; SSH keys accessible from the affected environment; and any database connection strings present in environment variables. Cryptocurrency wallets accessible from compromised systems should be migrated to new wallets generated on verified clean hardware, as the second-stage payload specifically targeted wallet extension data.

Network logs from build servers, developer workstations, and CI runners should be audited for connections to 23.254.164.92 or 23.254.164.123. The presence of persistence artifacts—Registry Run entries, LaunchAgent plists, or systemd units added around June 17, 2026—should be investigated on any system that ran an affected npm install.

Short-Term Mitigations

Teams should pin package versions explicitly in their lock files (package-lock.json or yarn.lock) and treat lock file commits as security-critical artifacts. Caret ranges (^) in package.json dependencies are operationally convenient but allow minor and patch version updates without explicit approval, which is the mechanism this attack exploited. Organizations managing AI developer tooling should evaluate whether their internal policies should restrict semver resolution to exact version pins for production build dependencies.

Integrating a software composition analysis (SCA) tool into CI/CD pipelines enables continuous monitoring of newly introduced transitive dependencies. Several vendors—including Snyk, OX Security, Socket, and Mend—published detection signatures for this campaign within hours of Microsoft’s initial disclosure on June 17, 2026 [5][7][8][12]; teams using these platforms should confirm their scans are current. Build pipelines should be configured to block or alert on postinstall hook execution from newly introduced transitive dependencies, as postinstall scripts represent the highest-risk execution surface in the npm ecosystem.

Scope maintainer lists should be audited immediately across all internal and open-source npm packages the organization maintains or depends on. Contributors who have not been active for six months or more warrant review, and any account with scope-wide publish access that is no longer operationally necessary should have its access revoked. Where npm supports it, two-factor authentication should be enforced for all publishing accounts.

Strategic Considerations

npm’s current trust model—which offers no automatic expiry of publishing permissions and no built-in scope access audit log—reflects design decisions from an era when package scopes were smaller and contributor turnover lower. The growing use of npm-hosted frameworks as foundational infrastructure for AI agent development substantially raises the consequences of scope-level compromises. Organizations building on AI frameworks sourced from the npm ecosystem should treat their dependency graph as part of their attack surface and apply the same access governance they would apply to internal systems.

Supply chain provenance verification is emerging as a practical control. The SLSA (Supply-chain Levels for Software Artifacts) framework [9] provides a graduated set of requirements for build integrity and artifact provenance. Packages with SLSA Level 2 or higher attestations provide cryptographically verifiable build provenance—evidence that the published artifact was produced by the claimed build system from the cited source commit. This substantially raises the bar for undetected tampering in the build pipeline, though it does not prevent account-level takeover of the registry publishing step itself, the vector exploited in the Mastra incident. Requiring SLSA attestations for high-impact dependencies, and using npm provenance fields where maintainers publish them, reduces the risk of build-pipeline tampering even where it does not fully address account-level takeover scenarios.

For organizations building agentic AI systems, the Mastra incident underscores that the AI agent’s dependency graph is part of its security posture. An AI agent framework with a compromised postinstall hook can exfiltrate the operator API keys that the agent uses to interact with LLM providers—effectively giving an attacker durable access to the AI system itself. Supply chain security for agentic AI is therefore inseparable from agentic AI security more broadly.

CSA Resource Alignment

This incident intersects directly with several areas of CSA’s AI safety and cloud security work. CSA’s MAESTRO framework (Multilayered Examination of Agentic Systems Targeting Risk and Operations) addresses the threat model for agentic AI systems, including supply chain compromise as an attack vector against agent runtimes. The Mastra attack demonstrates precisely the MAESTRO risk category of compromised AI tooling infrastructure: when the framework used to build, deploy, and orchestrate AI agents is itself backdoored, the entire trust chain of the agentic system is undermined.

The AI Controls Matrix (AICM), CSA’s superset of the Cloud Controls Matrix applied to AI contexts, includes control domains relevant to third-party component security, API key management, and build pipeline integrity. Specifically, AICM guidance on secure AI system development addresses vetting third-party AI libraries, enforcing access controls for publishing pipelines, and maintaining an inventory of AI-related dependencies. The Mastra incident provides a concrete case study for each of these control areas.

CSA’s guidance on Zero Trust architecture applies equally to software supply chains: no package or dependency should be implicitly trusted by virtue of its name or prior version history alone. The lesson from easy-day-js is that a package’s initial clean publication establishes no security guarantee about future versions. Zero Trust principles, applied to build pipelines, require continuous verification of artifact integrity at every install event rather than relying on a package’s established reputation.

CSA’s Agentic AI Red Teaming Guide and AI Organizational Responsibilities publications both address the organizational processes needed to assess and manage AI system risk. The Mastra compromise adds supply chain injection to the red team scenario catalog: a red team exercise that does not test whether CI/CD pipeline dependencies could introduce malicious postinstall hooks represents an incomplete assessment of an agentic AI system’s attack surface.

References

[1] Mastra. “TypeScript AI Agent Framework & Platform.” Mastra.ai, 2025.

[2] Orca Security. “144 Mastra npm Packages Compromised via Supply Chain Attack.” Orca Security Blog, June 2026.

[3] StepSecurity. “Mastra npm Supply Chain Attack: 140+ Packages Backdoored via easy-day-js Typosquat.” StepSecurity Blog, June 2026.

[4] The Hacker News. “145 Mastra npm Packages Compromised via Hijacked Contributor Account.” The Hacker News, June 2026.

[5] Snyk. “Mastra npm Scope Takeover: A Forgotten Contributor Account Compromised the Entire Mastra npm Package Scope.” Snyk Security Blog, June 2026.

[6] Microsoft Security Blog. “From Package to Postinstall Payload: Inside the Mastra npm Supply Chain Compromise.” Microsoft, June 17, 2026.

[7] OX Security. “easy-day-js Supply Chain Attack Hits Mastra AI in npm.” OX Security Blog, June 2026.

[8] Socket. “140+ Mastra npm Packages Compromised in Coordinated Supply Chain Attack.” Socket.dev Blog, June 2026.

[9] Open Source Security Foundation / Google. “SLSA: Supply-chain Levels for Software Artifacts.” slsa.dev, 2021–2026.

[10] Phoenix Security. “Easy-Day-JS / EASY_DAY_JS_MASTRA_2026: Typosquatted Dependency Delivers Cross-Platform RAT to 144 npm Packages.” Phoenix Security, June 2026.

[11] Kodem Security. “Mastra npm Compromise: easy-day-js Attack & Response — IOCs and Response Runbook.” Kodem Security, June 2026.

[12] Mend.io. “Mastra npm Scope Takeover: easy-day-js.” Mend.io Blog, June 2026.

[13] SafeDep. “Mastra npm Scope Takeover: 141 Packages Drop a RAT.” SafeDep, June 2026.

[14] Sonatype. “easy-day-js npm Campaign Targets Mastra as Malicious Dependency Attacks Grow.” Sonatype Blog, June 2026.