Lessons from the @mastra Supply Chain Attack

The real danger wasn't the malicious code. It was what that code found when it woke up.

Today, researchers at StepSecurity disclosed a live supply chain attack targeting the Mastra AI framework – one of the most widely used TypeScript frameworks for building AI agents, workflows, and RAG pipelines. Thirteen packages in the @mastra npm organization were compromised and pushed to developers doing nothing more suspicious than npm install.

The mechanics are clever. But the reason this attack is dangerous has nothing to do with the cleverness of the dropper. It has everything to do with where Mastra runs.

What Happened

On June 17, 2026, an attacker with access to the @mastra npm organization published malicious new versions of 13 packages across the Mastra AI framework ecosystem. The vector was a typosquatted package: easy-day-js – a newly created typosquat of the popular dayjs date library – was injected as a production dependency. The easy-day-js@1.11.22 package contains a postinstall hook that runs a heavily obfuscated setup.cjs file, which downloads and executes a second-stage payload, then self-deletes to remove forensic evidence.

The attack was methodical. On June 16, the attacker published a clean bait version of easy-day-js – mimicking dayjs's author field, homepage, and version numbering – designed to look credible. The next day, a malicious version was published with a postinstall hook added. Because the infected @mastra packages pinned the dependency as ^1.11.21, every fresh npm install pulled the malicious version automatically.

The dropper itself disabled TLS certificate validation, downloaded a second-stage payload from an attacker-controlled IP, spawned it as a detached process that outlives the install, and then deleted itself to destroy forensic evidence.

This is not a novel technique. What makes this incident worth paying close attention to is the target.

Why Mastra Environments Are Uniquely Dangerous to Compromise

Mastra packages are commonly installed in development environments, CI/CD pipelines, and production AI services – environments with access to high-value credentials including LLM API keys, cloud provider tokens, and database secrets.

That list is worth sitting with for a moment:

• LLM API keys (ANTHROPIC_API_KEY, OPENAI_API_KEY) – direct access to AI infrastructure, with real billing implications
• Cloud provider credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) – often with broad permissions
• VCS and CI/CD tokens (GITHUB_TOKEN, NPM_TOKEN) – the keys to your software supply chain itself

The attacker's stage-2 payload – which is downloaded at runtime and therefore invisible to static analysis – almost certainly targets exactly this set of credentials. The C2 infrastructure uses two IPs in the same /24 subnet, with a conventional 443 port for exfiltration: a setup optimized to blend into normal HTTPS traffic.

Here's the uncomfortable truth: the postinstall script wasn't the dangerous part. The dangerous part was what that script found when it ran.

Blocking the Execution Is Necessary – But Not Sufficient

Sweet's runtime sensors detect and block exactly this class of attack. When a postinstall hook spawns a child process, downloads a payload from a raw IP over a self-signed certificate, and attempts to beacon outbound – that's a detectable, blockable behavioral signature. Sweet customers running in cloud workloads or CI/CD environments would see the outbound connection attempt flagged and stopped before the second stage ever executes.

But let's assume, for a moment, that the attacker gets lucky. Or that a developer ran npm install locally before the malicious package was detected. Or that your CI pipeline ran during the narrow 36-minute window between the first compromised package being published and the incident being reported.

What happens next depends almost entirely on what the compromised process can reach.

The Real Question: What Entitlements Did That Process Inherit?

This is where the conversation shifts from incident response to security architecture – and where Sweet Entitlements becomes directly relevant.

Modern cloud workloads, CI runners, and AI service processes don't run in a vacuum. They run as identities – service accounts, IAM roles, Kubernetes service accounts, OIDC-federated principals – that carry permissions. And those permissions were almost certainly provisioned more broadly than necessary, because narrowing them down requires visibility that most teams simply don't have.

Consider a realistic Mastra deployment scenario: a Node.js service using @mastra/core to orchestrate AI workflows, running as an ECS task or GKE pod with an attached service account. That service account might have been given broad permissions during development – S3 access, Secrets Manager read, maybe even some IAM passthrough for downstream services. Nobody revisited it. The service has been running for eight months. Nobody knows what that role can actually reach.

That's the environment where a compromised postinstall script wakes up inside.

Sweet Entitlements was built specifically to make this problem visible. It surfaces the gap between the access an identity has and the access it actually uses – informed by runtime activity captured by the Sweet sensor, not just configuration snapshots.

For every service account, role, or workload identity across AWS, Azure, GCP, and Kubernetes, Entitlements shows:

• Every permission granted, directly or through inheritance
• A Last Seen timestamp for each permission – when it was last exercised
• The Last Consumer – which identity most recently assumed or invoked this identity
• Assume-chain relationships – how privileges flow transitively through your environment

An identity with twelve granted permissions but only one actively used isn't just wasteful. In a supply chain attack scenario, it's eleven permissions an attacker can abuse that you thought were inert.

What This Attack Looks Like Through the Entitlements Lens

Map the @mastra compromise against what Entitlements surfaces, and the risk calculus becomes concrete:

The CI/CD runner that installs npm packages – does it have secretsmanager:GetSecretValue? When was that permission last used legitimately? If it was provisioned six months ago for a one-off secret rotation and never touched again, that's a right-sizing opportunity that also happens to be an attacker's jackpot.

The production AI service running @mastra/core – what cloud APIs does its service account actually need to call? If the role was copied from a template and never scoped down, the attacker's stage-2 payload inherits everything on that template.

The developer workstation – less applicable to cloud Entitlements, but the same principle applies to locally cached credentials: ~/.aws/credentials, environment variables, stored tokens. If Mastra runs in an environment where a developer has long-lived cloud credentials, the blast radius extends to whatever those credentials can reach.

This is the insight at the heart of how Sweet thinks about supply chain attacks: the package is the delivery mechanism; the entitlements are the weapon.

Putting It Together: Defense in Depth That Actually Matches the Attack

Supply chain attacks like this one defeat perimeter-based and signature-based defenses almost by design. The package came from a legitimate registry, under a legitimate organization's namespace, with a clean bait version published first to establish credibility. By the time static scanners caught up, the window had already been open for over an hour.

What actually limits the damage is a layered posture:

Layer 1 – Block the execution. Sweet's runtime sensors detect the behavioral signature of a postinstall dropper: child process spawning, outbound connections to raw IPs, TLS verification disabled. Block this at the workload level and the second stage never runs.

Layer 2 – Contain the blast radius. Sweet Entitlements gives you a clear view of what a compromised process can reach – not what it theoretically could reach based on configuration, but what its identity has actually been exercising at runtime. Permissions that haven't been used in months are candidates for removal. Identities that shouldn't be in assume-role chains shouldn't be.

Layer 3 – Detect post-compromise behavior. If something does get through, Sweet's runtime visibility surfaces the anomalous behavior – unexpected outbound connections, credential access anomalies, unusual process trees – so the investigation starts with context, not guesswork.

The @mastra incident is a reminder that supply chain attacks are converging on a common playbook: compromise a trusted package, execute during install, harvest the credentials the environment already holds, and exfiltrate before anyone notices. The technical sophistication of the dropper matters less than the richness of the environment it lands in.

Shrinking that environment – knowing exactly what access exists, what access is actually being used, and what can be safely removed – is how you turn a potential incident into a near-miss.

Want to see what Entitlements reveal about your own environment? Talk to our team.