Hackers Compromised 140+ Mastra npm Packages to Deploy Infostealer Malware


Hackers compromised more than 140 Mastra npm packages in a supply chain attack that used a malicious dependency to run malware during installation.

The attack targeted the Mastra AI npm ecosystem, including packages under the mastra and @mastra scopes. According to Microsoft Security, the attacker took over the ehindero npm maintainer account and used it to publish poisoned package versions that added a new dependency called easy-day-js.

The affected packages did not need to be imported in application code for the malware to run. If a developer workstation or CI/CD pipeline installed one of the compromised versions, the malicious dependency could execute automatically through an npm postinstall script.

Mastra npm Attack Used a Typosquatted Dependency

The attack did not modify Mastra’s source code directly. Instead, the attacker added easy-day-js as a dependency in compromised package.json files.

Socket says the compromised package versions contained unmodified Mastra code, while the actual payload came from easy-day-js, a typosquatted copy of the popular dayjs date library.

The malicious package used a two-step trick. Version 1.11.21 of easy-day-js was published first as a clean copy of dayjs. Version 1.11.22 was published later with a postinstall hook that ran setup.cjs during npm install.

Attack detailWhat researchers found
Target ecosystemMastra and @mastra npm packages
Compromised publisherehindero npm account
Malicious dependencyeasy-day-js
Legitimate package impersonateddayjs
Execution methodnpm postinstall script
Primary riskDeveloper machines, CI/CD runners, tokens, credentials, and crypto wallets

Why the Malware Ran During npm Install

The compromised Mastra packages depended on easy-day-js using the version range ^1.11.21. Because npm’s dependency resolution accepts newer compatible versions in that range, installs resolved to easy-day-js 1.11.22 after the attacker published it.

The npm scripts documentation explains that package scripts can run at defined lifecycle events. In this case, the malicious package abused the postinstall lifecycle event to execute code automatically.

That made the campaign dangerous for build environments. A CI runner did not need to use Mastra in production code. Pulling the poisoned dependency tree during installation was enough to trigger the first-stage loader.

The First Stage Downloaded a Hidden Payload

The first-stage file, setup.cjs, was obfuscated to make static analysis harder. Microsoft says the dropper disabled TLS certificate verification, wrote tracking markers, contacted attacker-controlled infrastructure, and downloaded a second-stage payload.

The script fetched code from 23.254.164[.]92 on port 8000 and then launched it as a detached, hidden Node.js process. It also passed 23.254.164[.]123:443 as a second command-and-control address.

Aikido Security says the attacker republished 141 packages in a burst on June 17, 2026, and that @mastra/core alone had about 918,000 weekly npm downloads.

The Second Stage Acted Like a Cross-Platform Implant

The second-stage payload was not only a simple stealer. Researchers describe it as a cross-platform Node.js tasking client that can persist, beacon to its operator, receive commands, and run follow-on code.

On Windows, the implant can use a Registry Run key named NvmProtocal. On macOS, it can install a LaunchAgent named com.nvm.protocal.plist. On Linux, it can use a systemd user service named nvmconf.service.

The implant also inventories cryptocurrency wallet browser extensions, collects browser history from Chrome, Edge, and Brave, and performs host reconnaissance such as listing installed applications and running processes.

PlatformPersistence methodDisguise
WindowsRegistry Run keyNvmProtocal
macOSLaunchAgentcom.nvm.protocal.plist
Linuxsystemd user servicenvmconf.service

Attackers Targeted Developer and CI Secrets

Developer machines and build systems are valuable targets because they often contain tokens, cloud credentials, npm credentials, GitHub tokens, LLM API keys, SSH keys, deployment secrets, and access to private repositories.

Microsoft says compromised packages have been removed and the attacker’s publish access to the @mastra scope has been revoked. However, any system that installed affected versions during the exposure window should still be treated as potentially compromised.

The attack also shows how one stale maintainer account can create broad ecosystem risk when it still has publish rights. Researchers noted that legitimate Mastra releases had previously used trusted publishing, while the suspicious versions came from a manual publish path.

Package Provenance Could Have Helped Detection

npm trusted publishing uses OpenID Connect to let packages publish from supported CI/CD systems without long-lived tokens. npm says provenance provides cryptographic proof of where and how a package was built.

That matters because the malicious Mastra versions lacked the normal provenance pattern seen in prior releases. Security tools and policy checks that require provenance or trusted publishing can help flag unusual manual releases.

Provenance does not replace account security, lockfiles, or dependency scanning. It gives defenders another signal when a package that normally comes from CI suddenly appears through a different publishing route.

How Developers Can Check for Exposure

Developers should inspect projects, lockfiles, CI logs, and local node_modules directories for easy-day-js and affected Mastra versions. Any match should trigger credential rotation and host review.

  • Run npm ls easy-day-js in affected projects.
  • Search package-lock.json and other lockfiles for easy-day-js.
  • Review CI/CD logs from June 16 and June 17, 2026.
  • Check for outbound connections to 23.254.164[.]92 and 23.254.164[.]123.
  • Look for .pkg_history and .pkg_logs in temporary directories.
  • Search for unexpected random .js files in home or temp directories.
  • Remove affected package versions and pin known-good versions.

Aikido recommends treating any system that ran npm install on affected versions as compromised. For mastra, researchers recommend using known-good pre-incident versions and lockfiles while teams complete their investigation.

What Credentials Should Be Rotated

Credential rotation should not stop at npm tokens. The implant ran on developer and build systems, so it may have had access to many local secrets and environment variables.

Teams should rotate npm tokens, GitHub tokens, cloud provider credentials, CI/CD secrets, SSH keys, LLM API keys, package registry credentials, and any passwords stored in the affected environment.

For cryptocurrency wallets, teams should treat exposure as high risk. If a wallet seed, browser wallet storage, or extension data may have been reachable on the infected host, funds should move to a new wallet created on a clean device.

How to Reduce Risk From Postinstall Malware

The attack highlights a recurring weakness in JavaScript supply chains: install-time code execution. Malicious packages can run before a developer opens the library, reviews its API, or uses it in an application.

Socket says the payload executed during npm install before the package was imported or used. That makes install-time controls, dependency review, and network monitoring important parts of developer security.

Teams can reduce exposure by using npm install controls, enforcing lockfiles, delaying newly published packages, and monitoring unusual outbound connections from CI systems.

  • Use npm ci with committed lockfiles in CI.
  • Consider npm install --ignore-scripts for untrusted installs and analysis environments.
  • Block raw IP C2 traffic from build runners where possible.
  • Use dependency allowlists or package approval workflows.
  • Require provenance or trusted publishing for critical dependencies when feasible.
  • Set cooldown periods before accepting newly published package versions.
  • Audit maintainers and revoke stale publish permissions.

Key Indicators of Compromise

Security teams should use endpoint, network, and dependency indicators together. A lockfile hit alone may show exposure, while host artifacts and C2 traffic may show execution.

IndicatorTypeMeaning
easy-day-jsnpm packageMalicious typosquat used in the campaign
setup.cjsFilePostinstall dropper
protocal.cjsFileSecond-stage implant name reported by researchers
23.254.164[.]92IP addressPayload delivery server
23.254.164[.]123IP addressCommand-and-control server
.pkg_historyFile artifactInstall tracking marker
.pkg_logsFile artifactEncoded package marker
NvmProtocalWindows persistenceRegistry Run key value

The Mastra Incident Shows Why AI Developer Tools Are Targets

Mastra is used by developers building AI agents and applications, which makes its npm ecosystem attractive to attackers. A compromise in a popular AI development framework can reach local workstations, build runners, and deployment pipelines at the same time.

The npm ecosystem gives attackers speed. One compromised maintainer account, one typosquatted dependency, and one postinstall hook can create a large blast radius within minutes.

The best response is direct: remove affected packages, block the known infrastructure, rotate credentials, inspect hosts for persistence, and strengthen publish and install policies before the next package compromise.

FAQ

What happened in the Mastra npm supply chain attack?

Attackers compromised more than 140 Mastra npm packages by publishing poisoned versions that added a malicious dependency called easy-day-js. The dependency used a postinstall script to download and run malware during npm install.

Was Mastra’s source code changed?

Researchers say the compromised package code itself was largely unchanged. The attack worked by adding easy-day-js as a dependency in package.json, which caused npm to install the malicious version of that typosquatted package.

What did the easy-day-js malware do?

The malicious version of easy-day-js ran setup.cjs during installation, contacted attacker-controlled infrastructure, downloaded a second-stage Node.js implant, launched it as a hidden process, and attempted to persist on Windows, macOS, and Linux.

How can developers check if they were affected?

Developers should run npm ls easy-day-js, search lockfiles for easy-day-js, review CI logs from June 16 and June 17, 2026, and inspect hosts for .pkg_history, .pkg_logs, unusual .js files, and connections to 23.254.164[.]92 or 23.254.164[.]123.

What should teams do after exposure?

Teams should remove affected package versions, pin known-good versions, rotate npm tokens, GitHub tokens, cloud keys, CI/CD secrets, SSH keys, LLM API keys, and wallet credentials, and inspect affected systems for persistence before returning them to normal use.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages