Mastra npm Packages Compromised: The easy-day-js Typosquat, IOCs, and First-Hour Response

The @mastra npm scope was compromised on June 17, 2026, when a hijacked maintainer account republished more than 140 packages across the Mastra AI framework ecosystem, essentially the entire scope. This Mastra npm supply chain attack injected easy-day-js, a freshly created typosquat of the popular dayjs date library, as a production dependency on every affected package. That dependency carried a postinstall hook that ran an obfuscated setup.cjs dropper, disabled TLS validation, pulled a second-stage payload from attacker infrastructure, ran it as a detached process, and then deleted itself. The recovered second stage is a cross-platform cryptocurrency wallet stealer and remote access trojan. The compromise was analyzed by Microsoft Threat Intelligence, Socket, Snyk, JFrog, SafeDep and StepSecurity, and the Mastra maintainers tracked it in issue #18046.

No CVE has been assigned. The Mastra npm supply chain attack is part of a growing pattern of zero-CVE supply chain incidents, where attackers exploit structural gaps in the package ecosystem, in this case a dormant contributor account and unenforced publish provenance, rather than a traditional code vulnerability.

npm has since removed easy-day-js and revoked the ehindero account's access to the scope. Mastra forward-rolled clean releases in PR #18056 and moved the latest tag past the compromised versions, so @mastra/core latest is back to a clean 1.42.0.

This post covers what happened, how a forgotten account made it possible, what the dropper and the second stage do, the indicators of compromise, a first-hour runbook, and why answering the real question requires runtime evidence.

Attack Summary

The Mastra npm supply chain attack republished more than 140 @mastra packages on June 17, 2026 from a hijacked contributor account, each pulling a malicious easy-day-js dropper that delivered a cross-platform crypto-stealer and RAT. Any developer workstation, CI runner, or build agent that resolved an affected version during the exposure window should be treated as a compromised host.

Sources: Microsoft Threat Intelligence, Socket, Snyk, and the Mastra maintainers' issue #18046.

Why @mastra Is a High-Value Supply Chain Target

The @mastra packages install on developer laptops, in CI/CD pipelines, and in production AI services, the same environments that hold LLM API keys, cloud tokens, database credentials, and, on developer machines, cryptocurrency wallets. A compromise of the scope's dependency tree is therefore a foothold across every team that resolved a malicious version, not the compromise of a single application.

Mastra is an open-source TypeScript framework for building AI agents, workflows, and RAG pipelines, with a large scope that is widely pulled. @mastra/core alone draws roughly 4 million downloads a month, about 918K weekly, and has hundreds of dependent projects, so the aggregate blast radius across 142 republished packages runs into the tens of millions of monthly installs. A host was exposed before any developer imported or ran the package, because the payload fires during installation.

How the easy-day-js Attack Unfolded

The attack succeeded on project hygiene rather than a zero-day: a stale maintainer credential pushed a one-line dependency change across the whole scope, and the change pulled a trojan at install time. The campaign ran in two publish phases over two days after the account was taken over.

The foothold: a forgotten contributor account

The @mastra scope was republished using ehindero, a real former Mastra contributor whose account published legitimate @mastra/core alpha releases in late 2024 and early 2025 and then went dormant. The account's scope publish access was never revoked, and npm does not expire publish permissions on inactivity, so one stale credential was enough to push to every package in the scope. Microsoft Threat Intelligence flagged the takeover through a publishing anomaly: every prior mastra release shipped through GitHub Actions OIDC, but [email protected] was manually published by ehindero from an anonymous Tutamail address ([email protected]), the only change from [email protected] being the injected easy-day-js dependency. The typosquat publisher sergey2016 used the same Tutamail provider ([email protected]), linking the two accounts.

Mastra also generated SLSA provenance attestations on its CI publishes but did not require them, so a plain npm token could still publish without attestations. An install that verifies signatures, through npm audit signatures or a policy that requires provenance, would have rejected every package in this wave.

Phase 1: A typosquat built to look real (June 16)

The npm account sergey2016 published [email protected] at 07:05 UTC on June 16, a byte-for-byte clone of the legitimate dayjs library down to the bundled dayjs.min.js, with no postinstall hook and no malicious files. The metadata impersonated dayjs: the claimed author was iamkun, and the repository URL pointed at github.com/iamkun/dayjs. This release was the clean bait.

Phase 2: Scope takeover and mass publish (June 17)

The attacker published [email protected] at 01:01 UTC on June 17, identical to the bait except for the addition of setup.cjs and its postinstall hook, and tagged the malicious release latest. Each republished @mastra package added exactly one line to its package.json:

"easy-day-js": "^1.11.21"

The caret range ^1.11.21 resolves to the latest matching version at install time, so a normal npm install resolved straight to the armed [email protected]. In a burst between roughly 01:12 and 02:36 UTC, an 88-minute window, the ehindero account republished the rest of the scope, including @mastra/[email protected], [email protected], and [email protected]. For a handful of packages the attacker published versions above the legitimate latest, which later forced Mastra to pin explicit higher releases rather than ordinary patch bumps. The full list of affected packages and versions is in the appendix below.

What the setup.cjs Dropper Does

The setup.cjs dropper runs at install time through the postinstall hook, then disables TLS validation, writes beacon files to the temp directory, fetches and spawns a detached second stage, and deletes itself. When npm installs any infected @mastra package, npm resolves easy-day-js to 1.11.22 and runs the hook:

"postinstall": "node setup.cjs --no-warnings"

The --no-warnings flag suppresses the Node.js deprecation and experimental notices that might otherwise catch a developer's eye. The setup.cjs file is 4,572 bytes and heavily obfuscated: an array of 40 Base64-encoded strings is shuffled at initialization with a numeric seed (0x4c11d), then read through a custom Base64 decoder with character substitution, which blocks static string extraction. Stripped of the obfuscation, the logic is a compact five-step sequence:

• The dropper sets NODE_TLS_REJECT_UNAUTHORIZED='0', disabling TLS certificate validation so the next stage can be served over a self-signed certificate on a raw IP.
• The dropper writes two markers in the OS temp directory: .pkg_history holds the install path of the compromised package, and .pkg_logs holds the package name encoded with XOR 0x80.
• The dropper issues a GET request to https://23.254.164.92:8000/update/49890878 and reads the response body as the second stage.
• The dropper writes that body to a random-named .js file in the temp directory and spawns the file with node using detached: true, stdio: 'ignore', and .unref(), so the process outlives the install and produces no output.
• The dropper deletes setup.cjs with fs.rmSync(__filename, { force: true }), removing the first-stage evidence from disk.

What the Second Stage Does

The second-stage payload is a roughly 41 KB cross-platform Node.js cryptocurrency wallet stealer and remote access trojan, recovered and reversed by Socket, Snyk and Microsoft from attacker infrastructure rather than from the package itself. The implant inventories cryptocurrency wallet browser extensions, harvests browser and host data, installs login persistence on Windows, macOS, and Linux, and beacons to a C2 server that can push and run arbitrary follow-on code.

The collection stage matches a hardcoded list of 166 wallet browser-extension IDs, including MetaMask, Phantom, Solflare, Coinbase Wallet, Binance Wallet, OKX, Keplr, and TronLink, against Chrome, Edge, and Brave profiles, then copies each profile's browser history and gathers hostname, OS, architecture, Node version, installed applications, and the running process list. The implant beacons to 23.254.164.123 over port 443 roughly every 10 minutes using a self-signed wolfSSL test certificate, and honors update and exit commands, so the operator can run a Node runner or a shell runner on the host at any time. On Windows, the chain additionally performs reflective .NET assembly injection into a cmd.exe process for fileless in-memory execution.

Removing the package after the fact does not undo the compromise, because the second stage runs detached and installs persistence. Any LLM API keys, cloud credentials such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, version-control tokens such as GITHUB_TOKEN and NPM_TOKEN, and wallet seeds present on an affected host should be treated as exposed.

Indicators of Compromise

Treat any environment that ran npm install or npm update for an affected package on or after 01:01 UTC on June 17, 2026 as potentially compromised, and prioritize hosts that resolved a malicious version through a loose range or a fresh lockfile. Hunt for the following.

File hashes (SHA256):

Immediate Response: The First-Hour Runbook

Priority is to assume host compromise and credential exposure and to hunt persistence, not just to remove the package, because the dropper runs at install time and the second stage installs a persistent RAT. Work the steps in order.

1. Upgrade to clean versions, and do not just pin downward. Remove easy-day-js entirely, move to current clean Mastra releases ([email protected] and earlier are unaffected, @mastra/[email protected] and earlier are unaffected, and Mastra forward-rolled clean releases in PR #18056), and regenerate a clean lockfile.
2. Find every instance. Run npm ls easy-day-js and grep -r "easy-day-js" package-lock.json yarn.lock pnpm-lock.yaml across repos and CI, because the dependency was transitive through @mastra and will not appear in your top-level package.json.
3. Hunt persistence and kill the process. Check for ~/Library/LaunchAgents/com.nvm.protocal.plist, ~/.config/systemd/nvmconf.service, and the NvmProtocal Run key plus C:\ProgramData\NodePackages\, kill the detached node process, and delete the .pkg_history and .pkg_logs markers.
4. Move cryptocurrency wallets. If a browser profile on the host held a targeted wallet extension, assume the seed and keys are exposed and transfer funds to a fresh wallet on a clean device.
5. Rotate exposed secrets. Rotate cloud keys, CI secrets, LLM API keys, GITHUB_TOKEN, NPM_TOKEN, and SSH and Git credentials for any host that ran the install.
6. Block the infrastructure. Block outbound traffic to 23.254.164.92, 23.254.164.123, and the 23.254.164.0/24 range, and alert on any historical connections.
7. Reimage where practical. For a RAT with established persistence, a clean rebuild is the safest outcome.
8. Inspect CI runners. Prioritize ephemeral build agents that ran a fresh install, because their tokens are often broadly scoped and rarely rotated.

Why a Dependency Scan Does Not Settle This

A dependency scanner tells you easy-day-js is in your tree, but the scanner cannot tell you whether the postinstall hook executed, whether the second stage was fetched, whether persistence was installed, or whether wallets and tokens left the host. For an install-time dropper that drops a persistent RAT, that gap is the entire incident. Severity without execution context is noise, and "the package is present" is a starting point rather than an answer.

That gap between presence and execution is where Kodem operates.

• Kodem's SCA surfaces every copy of easy-day-js and every affected @mastra version across direct and transitive dependency trees, so scope-wide inventory takes minutes rather than a day of grepping lockfiles.
• Runtime Intelligence, Kodem's patented foundational layer, confirms what actually executed: whether the install ran, whether the dropper spawned a detached process, and whether outbound connections to the C2 infrastructure occurred.
• Kodem's Application Detection and Response layer catches the behavior this attack depends on, an unexpected subprocess spawned during install and a callout to fresh infrastructure, detected at the moment it happens and without waiting for a signature.
• Kai folds that evidence into a prioritized response, so the team spends the first hour rotating the right credentials and reimaging the right hosts instead of guessing which environments were exposed.

Hardening Against the Next postinstall Dropper

Install-time execution from a hijacked maintainer account is the recurring pattern in npm supply chain attacks, and shrinking its blast radius is mostly a configuration and hygiene problem you can solve before the next one lands. Adopt the following controls now.

1. Disable install scripts by default in CI with npm install --ignore-scripts, and allowlist the few packages that genuinely need them.
2. Require provenance on consumption with npm audit signatures or a policy that rejects unattested packages, which would have blocked this entire wave.
3. Revoke dormant maintainer and scope access, and review who can publish to each scope, because a forgotten contributor credential was the root cause here.
4. Pin dependencies with a committed lockfile and use npm ci, so a flipped latest tag cannot silently re-resolve a build.
5. Adopt an install cooldown so brand-new package versions cannot be pulled into builds within hours of publication.
6. Maintain a current SBOM so a newly disclosed package can be located across every service in minutes.
7. Monitor runtime behavior on developer machines and build agents for unexpected subprocess execution, persistence writes, and outbound connections to new infrastructure.

What This Signals for AI Framework Supply Chains

AI agent frameworks have become high-value supply chain targets because they sit next to the most valuable secrets in a modern stack and run installs constantly, and the absence of a CVE here is the point, not a footnote.

• The compromise rode a structural ecosystem gap, a never-revoked contributor credential plus unenforced provenance, rather than a code vulnerability, so no CVE was ever in scope.
• The decoy was seeded a full day in advance, and the weaponized publish swept the scope in an 88-minute window, faster than any advisory-and-scanner-rule cycle.
• The malicious behavior, an install-time process spawning a detached child and beaconing to fresh infrastructure, is observable the moment it happens.

Detection that waits for a CVE to be assigned, an advisory to be written, and a scanner rule to be updated is measured in days against an attack measured in minutes. Expect more zero-CVE compromises of AI framework dependency trees, and expect the useful question to keep shifting from "is the package present" to "did it execute here."

Frequently Asked Questions

The Bottom Line

The Mastra npm supply chain attack is not exotic. A dormant contributor account, a convincing typosquat, a caret version range, and a postinstall hook were enough to push a crypto-stealing RAT across essentially the entire @mastra scope, with no CVE and no change to Mastra's source code. The fix is straightforward: upgrade to clean versions, remove easy-day-js, rotate exposed secrets, and hunt persistence on any host that ran the install. The harder problem is knowing where the dropper actually ran and what it touched, which is a runtime question rather than a scanner question, and the part Kodem connects from code to runtime.

Appendix: Affected Packages and Versions

The following affected list contains 141 packages under the @mastra/* scope, plus mastra, create-mastra, and the malicious easy-day-js, with affected versions reproduced verbatim from the incident data.

Fixed versions are the clean patch releases Mastra forward-rolled in PR #18056, shown as the next patch above each affected version. Remove easy-day-js entirely, since the package is malicious and has no safe version.

Verify any fixed string against npm before blocklisting, because Mastra published no explicit per-package version list, three packages (@mastra/dane, @mastra/node-audio, @mastra/node-speaker) were remediated outside that changeset, and three (@mastra/schema-compat, @mastra/react, @mastra/voice-playai) required a larger bump via PR #18060.