Attackers compromised the Mastra AI framework’s npm publishing path on June 17, republishing more than 140 @mastra packages with a malicious dependency that runs during installation. The incident is a sharp warning for teams building AI agents: the software supply chain around agent frameworks now carries the same credential-theft risk as the agents themselves.
Security researchers at StepSecurity, Aikido Security, SafeDep, Endor Labs, and OX Security reported overlapping findings on the campaign. The affected ecosystem includes widely used packages such as @mastra/core, mastra, create-mastra, @mastra/mcp, @mastra/rag, database adapters, observability integrations, deployer packages, and other components used to build TypeScript-based AI applications and agent workflows.
What Happened
The attacker’s move was subtle. The Mastra package code was not rewritten with obvious malware. Instead, compromised releases added a single production dependency: easy-day-js, a typosquatted clone of the popular dayjs date library.
The setup appears to have started on June 16, when an attacker-controlled account published [email protected] as a clean copy of dayjs. That made the package look harmless during a casual review. On June 17 at about 01:01 UTC, researchers say a new [email protected] version appeared with a postinstall hook that ran an obfuscated setup.cjs script.
Minutes later, a compromised Mastra npm account republished large parts of the @mastra scope with a dependency range of ^1.11.21. That range is the key detail: npm can resolve it to the later malicious 1.11.22 release during a fresh install, even though the dependency line points back to the clean-looking earlier version.
Aikido described 141 packages republished in a burst roughly between 01:15 and 02:00 UTC. SafeDep reported a similar 141-package scope and said the attacker used an older Mastra contributor account with publish access. Endor Labs counted a narrower set of 116 packages in its table but estimated the affected catalog’s combined reach at more than 28 million downloads a month. The exact count may shift as researchers and registries reconcile affected versions, but the core pattern is consistent across reports.
How the Payload Worked
The malicious easy-day-js release used npm’s install lifecycle rather than waiting for an application to import the package. Its postinstall script executed automatically when npm installed the dependency, a familiar attack path in JavaScript supply-chain incidents.
Researchers who deobfuscated the script found that it disabled TLS certificate validation, fetched a second-stage payload from an attacker-controlled IP address, wrote that payload to a randomly named JavaScript file in a temporary directory, launched it as a detached background process, and then tried to remove evidence of the installer script. Aikido and SafeDep reported command-and-control infrastructure at 23.254.164.92 and 23.254.164.123.
The second-stage behavior reported by researchers focused heavily on cryptocurrency theft and persistence, including attempts to collect information from browser-based wallet extensions such as MetaMask and Coinbase Wallet. For engineering teams, the more practical concern is broader exposure: Mastra projects often live on developer machines and CI runners that may also contain LLM API keys, GitHub tokens, npm publishing tokens, cloud credentials, database URLs, and deployment secrets.
Why This Hits AI Developers Differently
Mastra is built for AI agents, multi-step workflows, retrieval-augmented generation pipelines, Model Context Protocol integrations, memory, evaluation, deployment, and provider connections. That makes it useful software, but it also means a compromised install can land in unusually credential-rich environments.
A traditional web dependency compromise is already serious. An AI-agent framework compromise can be worse because the surrounding projects often connect to OpenAI, Anthropic, Google, vector databases, observability services, cloud hosts, Git providers, and internal tools. A poisoned package does not need to understand the agent application. It only needs to run on the same machine as the secrets that make the application work.
The incident also shows why provenance and install policy matter. SafeDep reported that legitimate Mastra releases normally carried SLSA provenance from the project’s GitHub Actions pipeline, while the malicious releases were pushed from a personal token without that attestation. In environments that enforce provenance or signature checks, that difference can become a blocking signal instead of a clue found after the fact.
What Developers Should Check Now
Teams that installed or updated Mastra packages on June 17 should not treat this as a normal dependency cleanup. The safer assumption is that any affected developer machine or CI runner may have executed untrusted code.
- Search lockfiles for
easy-day-js,@mastra/, andmastra, especially installs or lockfile changes created on June 17. - Run
npm ls easy-day-jsin affected projects and inspect dependency trees for any unexpected Mastra versions published during the incident window. - Roll Mastra dependencies back to pre-incident versions or known-good releases with expected provenance.
- Block
easy-day-jsat the registry, package manager, or dependency policy layer. - Rotate secrets exposed to affected machines or CI jobs, including LLM provider keys, GitHub tokens, npm tokens, cloud credentials, database credentials, and wallet-related secrets where relevant.
- Review developer workstations and runners for suspicious temporary JavaScript files, unexpected background Node processes, and indicators published by the security firms tracking the campaign.
- Rebuild clean CI runners rather than assuming a package removal fully removes the second-stage payload.
Developers should also look beyond direct dependencies. If a project uses a starter template, agent example, internal framework wrapper, or generated application scaffold that pulls in Mastra packages, the affected package may appear in a lockfile even when no one installed it by hand.
The Larger Pattern
The Mastra compromise lands after a string of 2026 package-registry attacks that targeted developer infrastructure rather than consumer devices. npm has already seen compromises involving maintainer accounts, typosquatted dependencies, install-time payloads, and malware that reaches into GitHub, cloud, and CI/CD environments.
This case is notable because the target was an AI agent framework. As more teams build automation around LLMs, the packages that connect models, tools, memory, databases, and deployment targets become high-value distribution points. A single poisoned dependency can sit upstream of many agent projects, and the machines installing those projects often have exactly the credentials attackers want.
The short-term response is straightforward: check for affected Mastra packages, rotate secrets, and rebuild untrusted environments. The longer-term lesson is harder but more durable. AI development teams need the same install controls, provenance enforcement, package cooldowns, registry blocklists, and secret-isolation practices that mature security teams already apply to production build pipelines. Agent frameworks are now part of the software supply chain attack surface, not just a layer above it.
