# 144 Mastra npm Packages Backdoored: What to Check Right Now > Source: > Published: 2026-06-17 11:16:13+00:00 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-js ``` Any output means you installed a compromised version. Start rotating credentials now. Details below. ## What Mastra Is If you have not encountered it yet: [Mastra](https://mastra.ai/) 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`.js` files, and`browser-hist-*` directories. Check for a detached`node` process 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-scripts ``` The `--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](https://socket.dev/blog/mastra-npm-packages-compromised). 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](https://thehackernews.com/2026/06/144-mastra-npm-packages-compromised-via.html) and [StepSecurity’s writeup](https://www.stepsecurity.io/blog/mastra-npm-packages-compromised-using-easy-day-js). Add `--ignore-scripts` to your pipelines today.