The Mastra npm Attack: Why One Dependency Can Drain Your Secrets

On June 17, 2026, a developer who ran npm install @mastra/core to build an AI agent could have handed an attacker their OpenAI key, their AWS credentials, and their GitHub token — without typing a wrong command, clicking a bad link, or making any mistake at all. They just installed a popular package on the day it was poisoned. Over an 88-minute window that morning, attackers republished more than 140 packages across the Mastra AI-framework ecosystem with a hidden malicious dependency, and every fresh install pulled it down (StepSecurity). If your product is built on a fast-moving AI framework — and a lot of products shipped in the last year are — this is the incident to understand, because the business lesson generalizes far beyond Mastra.

What actually happened?

Mastra is a widely used open-source TypeScript framework for building AI agents, RAG pipelines, and multi-step workflows, with native hooks into OpenAI, Anthropic, and Google. According to StepSecurity's analysis, on June 17, 2026 an attacker with compromised access to the @mastra npm organization republished 140+ of its packages, quietly adding a single new dependency: easy-day-js, a typosquat of the hugely popular dayjs date library (StepSecurity). Microsoft's threat-intelligence team tracked the same campaign and attributed it to a state-aligned actor it calls Sapphire Sleet (Microsoft Security Blog).

The mechanics are worth understanding in plain terms because they explain why no individual developer "did anything wrong":

• The bait was planted first. A day earlier, the attacker published a clean, fully working copy of easy-day-js that copied dayjs's author name, homepage, repository, and license wholesale — so it would pass a casual glance at a dependency list (StepSecurity).
• The trap sprang automatically. Mastra's packages pinned the dependency loosely (^1.11.21), which tells npm to grab the newest matching version at install time. When the attacker later published a malicious 1.11.22, every new install pulled the payload — no further edits to Mastra needed (StepSecurity).
• The payload ran at install, then hid. The malicious version carried a postinstall script that ran on npm install, downloaded a second-stage program from an attacker server, launched it as a detached background process, and then deleted itself to erase the evidence (StepSecurity).

The likely goal, given where Mastra runs, was to harvest the secrets sitting in those environments — LLM API keys, cloud credentials, and CI/CD tokens — and ship them off to the attacker.

Why does this hit founders harder than it looks?

Because the damage isn't "a date library got hacked." It's the value of what lives next to your code. Mastra environments routinely hold the keys to your most expensive and most sensitive systems: OPENAI_API_KEY, AWS_ACCESS_KEY_ID, database connection strings, and GITHUB_TOKEN (StepSecurity). Translate each into a business outcome:

• A leaked LLM key is a metered bill someone else runs up — model-API abuse can rack up real money before you notice the spend.
• A leaked cloud credential can mean data access, resource hijacking (often crypto-mining on your card), or a path deeper into your infrastructure.
• A leaked GitHub token can expose private source code and, worse, let the attacker poison your releases the same way Mastra's were poisoned — turning you into the next link in the chain.

This is also not a one-off. Black Duck's 2026 Open Source Security and Risk Analysis report, based on 947 commercial codebases, found that 65% of organizations experienced a software supply chain attack in the past year, and that 66% of those attacks involved malicious packages purpose-built to harm users through tactics like typosquatting — exactly what happened here (Black Duck). The Mastra incident isn't an outlier; it's the median attack of 2026.

Why is the AI-framework era especially exposed?

Two things compound. First, AI frameworks are young, fast-moving, and installed in exactly the environments where the richest secrets live — so a single compromised package yields an unusually high payoff. Second, the broader codebase around them is increasingly assembled faster than anyone can review it. The same Black Duck report found the average number of files per codebase grew 74% year over year and open-source components grew 30%, driven by AI coding assistants (Black Duck). More dependencies, added faster, by tools that don't pause to ask "do I trust this package's maintainer?" means a larger attack surface that fewer people are actually watching.

That's the narrative founders need to internalize: shipping speed has outrun shipping oversight. The dependency you added through an AI assistant at 2pm is one you've probably never read — and neither has anyone else on your team.

What should a founder actually do this week?

You don't need to become a security engineer. You need a short, repeatable discipline. Here's a five-point founder checklist drawn directly from how the Mastra attack worked:

1. Rotate first, investigate second — if you installed any @mastra package around June 17. Assume the secrets in that environment are compromised: rotate LLM keys, cloud credentials, and tokens. Rotation costs an afternoon; a live key in an attacker's hands is open-ended.
2. Pin your dependencies and use a lockfile. Loose version ranges (^1.11.21) are what let the poisoned version flow in automatically. Committed lockfiles and exact pins mean a newly published malicious version doesn't silently appear on the next install.
3. Add a cooldown on new package versions. Most malicious packages are caught within hours. A policy of not installing brand-new versions immediately — a short quarantine window — would have sidestepped this entire incident.
4. Treat secrets as rotatable by default. Keep every API key and token in a secrets manager, not in code, and have a one-command rotation path ready before you need it. The companies that recover fastest are the ones who rehearsed.
5. Know your dependency inventory. You can't protect against a compromised package you don't know you have. A software bill of materials makes "are we affected?" a five-minute query instead of a frantic afternoon — see what an SBOM is, for founders.

Where an automated audit fits

The honest limit: no scan catches a zero-day supply-chain compromise in the first minutes after it's published — the cooldown discipline above is what handles that. What an audit does give you is the thing this incident punishes hardest to lack: visibility. Knowing every package your system depends on, which of them run install-time scripts, where your secrets are stored, and whether any are sitting exposed in your repository is the difference between answering "are we affected?" in minutes versus days. SystemAudit's free scan maps your dependencies and flags exposed secrets and risky configuration from a GitHub link in under three minutes, in business terms a non-technical founder can act on — run a free scan. It won't stop tomorrow's typosquat, but it makes sure you're not already carrying yesterday's.

For the wider pattern, our breakdown of the npm and PyPI supply-chain worm wave of 2026 shows how these self-propagating attacks spread, and the LiteLLM supply-chain attack analysis walks a closely related AI-tooling incident. If your worry is leaked credentials specifically, how to find exposed secrets in GitHub is the practical next read.

Frequently asked questions

Was I affected if I use Mastra but didn't install anything on June 17?

Possibly not — the risk window is tied to installing or reinstalling affected @mastra packages while the malicious easy-day-js@1.11.22 was being served. If your build didn't pull a fresh copy during that window and your lockfile held an earlier, clean resolution, you may have avoided it. But because the payload harvested secrets, the safe posture if you're unsure is to rotate credentials and check your install logs around June 17, 2026.

How did the attackers get into the Mastra organization in the first place?

According to StepSecurity's analysis, the mass republish was performed using compromised @mastra organization publishing credentials — an account with access that allowed pushing new versions of the org's packages (StepSecurity). The broader lesson is that a maintainer account with un-revoked publishing rights is a single point of failure for everyone downstream.

Could a vulnerability scanner have caught this before install?

Not in the first minutes. This was a freshly published malicious version, so there was no CVE or advisory yet when the attack began. That's exactly why the durable defenses here are structural — pinned dependencies, lockfiles, and a cooldown window on new versions — rather than relying on a scanner to already know the package is bad.

What's the realistic financial damage from an incident like this?

It depends entirely on what secrets were in the environment. The most common immediate costs are runaway charges on stolen LLM and cloud keys, incident-response time, and credential rotation across systems. The more serious tail risk is a leaked source-code or release token that lets an attacker compromise your own product — which can escalate into a customer-facing breach.

Does pinning dependencies really help, or just slow me down?

It genuinely helps. Loose version ranges are what allowed the poisoned 1.11.22 to flow in automatically the moment it was published. Exact pins plus a committed lockfile mean your builds keep using the version you vetted until you deliberately choose to upgrade — turning a silent automatic compromise into a conscious, reviewable decision.

This analysis reflects publicly reported details of the Mastra npm supply-chain compromise as of late June 2026; investigations of this kind continue to evolve, and some specifics may change as more is disclosed. The defensive steps above apply to any dependency you install, not just this one.