By ByteBot
Between 01:15 and 02:36 UTC this morning, an attacker hijacked a dormant contributor account and published malicious versions of 144 packages under the @mastra npm scope. Mastra is a TypeScript AI agent framework with over 1.1 million combined weekly downloads. If you ran npm install on any @mastra/* package in the last 24 hours, run this before reading further:
npm ls easy-day-jsAny output means you installed a compromised version. Start rotating credentials now. Details below.
What Mastra Is
If you have not encountered it yet: Mastra is an open-source TypeScript framework for building production AI agents, created by the team behind Gatsby and backed by Y Combinator (W25 batch). It handles agents, workflows, memory, Model Context Protocol (MCP) servers, and observability — the full stack for TypeScript developers building AI applications. It has 22,000+ GitHub stars, it is in production at Replit and WorkOS, and its core package alone sees 918,000 weekly downloads. This is not a niche framework.
How the Attack Worked
The attacker did not exploit a zero-day in Mastra’s code. They used a much simpler vector: a former contributor account called “ehindero” still had publish access to the @mastra npm scope. Contributor access was never revoked after they stopped contributing. The attacker compromised that account and, within an 81-minute window, published malicious new versions of 141 packages under the @mastra scope.
The mechanism was a typosquatted dependency called easy-day-js — a clone of the popular dayjs date library with one extra feature: a postinstall script. When npm resolves and installs easy-day-js, that script fires automatically. It disables TLS certificate validation, downloads a second-stage payload from attacker-controlled infrastructure, executes it as a detached background process, and then deletes itself to remove forensic traces.
Here is the part that makes this particularly nasty: the @mastra/* packages themselves are clean. If you review the source of a compromised Mastra package, you will find nothing wrong. The malicious behavior lives entirely in the transitive dependency. You will not catch this with a source review — only a full dependency tree audit will surface it.
What the Payload Does
The second-stage payload is a cross-platform infostealer targeting Windows, macOS, and Linux. It exfiltrates a beacon over HTTPS containing your username, hostname, OS and architecture, Node version, list of installed applications, running processes, and browser history. Its primary targets are cryptocurrency wallet browser extensions — it has a hardcoded list of 166 extensions including MetaMask, Phantom, Coinbase Wallet, Solflare, OKX, and Keplr. It also installs persistence, meaning it survives the terminal session that installed the malicious package.
If npm ls easy-day-js Returns Output
Assume the host is compromised. Here is the response sequence:
- Delete and reinstall: Remove
node_modules, clear your npm cache, and reinstall using a version of the@mastra/*packages that predates June 16, 2026. - Rotate credentials: npm tokens, cloud provider keys (AWS, GCP, Azure), CI/CD secrets (GitHub Actions, CircleCI), LLM API keys (OpenAI, Anthropic, Groq), SSH keys, and any cryptocurrency wallets accessible from that machine.
- Hunt artifacts: Check your temp directory for
.pkg_history,.pkg_logs, randomly named 24-hex.jsfiles, andbrowser-hist-*directories. Check for a detachednodeprocess that should not be there. - Treat any CI runner that ran the install as compromised, not just developer machines.
Prevention: What Would Have Stopped This
Two things would have blocked the attack at install time:
# Block all postinstall scripts (the attack vector)
npm install --ignore-scripts
# In CI: verify lockfile integrity and block scripts
npm ci --ignore-scriptsThe --ignore-scripts flag is not new, but few teams use it by default. Every supply chain attack in the past year that used a postinstall vector would have been stopped by it.
The structural issue — stale contributor access — is harder to fix. npm has no built-in expiry for publish permissions. This exact vector, a former contributor account whose scope access was never cleaned up, was also used in the TanStack attack. The Mastra team is not uniquely at fault here; this is an ecosystem-level failure. But every maintainer team should be auditing publish permissions on a regular schedule and removing access for contributors who are no longer active.
The Bigger Picture
This is the third significant npm supply chain attack in six weeks: the Red Hat Cloud Services attack on June 1, the LinkedIn job-offer backdoor on June 16, and now this. The pattern is consistent — compromised credentials, postinstall execution, credential theft. The individual remediation steps are clear. What is missing is the industry-level enforcement: automatic scope expiry for inactive contributors, lifecycle script sandboxing by default, and better tooling to surface transitive dependency changes in package diffs.
Until that infrastructure exists, npm ci --ignore-scripts in CI is not optional for any team that cares about supply chain security. Full technical details are available from The Hacker News and StepSecurity’s writeup. Add --ignore-scripts to your pipelines today.
