Mastra npm Compromise: How WCS Blocks Malicious Payloads Even After a Poisoned Dependency Is Installed

A trusted AI framework became a delivery path for a malicious dependency — and that makes supply-chain security an execution-control problem, not just a detection problem

Date: June 22, 2026 Primary Source: StepSecurity (StepSecurity) · Microsoft Threat Intelligence (Microsoft)

Mastra npm supply-chain compromise via the easy-day-js dependency — White Cloud Security Default-Deny Zero-Trust Application Control blocks the postinstall payload from executing

Executive Summary

What: Attackers compromised the @mastra npm organization and republished 140+ packages with a malicious dependency, easy-day-js (a typosquat of dayjs), whose obfuscated postinstall script downloaded and ran a second-stage payload.
Who is affected: Developers, CI runners, and build systems that installed affected @mastra packages — a set with 1.1M+ combined weekly downloads. Microsoft attributes the campaign to the North Korean group Sapphire Sleet.
Severity: High — credential, cloud-key, and crypto-wallet theft via a cross-platform RAT, delivered through a trusted package channel.
Action required: Treat supply-chain compromise as an execution-control problem. Add a Default-Deny layer so unauthorized payloads cannot run even after a poisoned dependency lands on disk — alongside SCA, SBOMs, lockfiles, and CI/CD hardening.

Overview

Software supply-chain security cannot rely only on package reputation, package names, or developer trust. The Mastra incident is a clean example: a legitimate AI development framework became the delivery path for a malicious dependency that executed during a routine npm install.

Mastra is a TypeScript framework for building AI agents and AI applications. According to StepSecurity, on June 17, 2026 an attacker used a dormant, never-revoked former-contributor credential to publish across the @mastra namespace, quietly adding easy-day-js as a production dependency to 140+ packages over roughly 88 minutes. (StepSecurity) The dependency mimicked the popular dayjs library — copying its version numbering, author metadata, homepage, and license — so it could pass a casual visual inspection. (StepSecurity)

The malicious easy-day-js carried an obfuscated postinstall hook (setup.cjs) that fetched and ran a second-stage payload from attacker infrastructure, then self-deleted. Microsoft Threat Intelligence analyzed the postinstall payload and attributed the campaign to Sapphire Sleet — the same North Korean actor tied to the earlier Axios npm compromise. (Microsoft) The carrier @mastra packages looked clean because the malicious logic rode in through a dependency rather than being embedded directly in each package.

The key lesson for defenders: installation does not equal authorization. A package manager delivering a file to disk is not the same as that file being permitted to execute — and that distinction is exactly where White Cloud Security (WCS) Trust Lockdown applies.

Threat Summary

Field	Detail
Incident	`@mastra` npm organization compromise (supply-chain)
Disclosure	June 17, 2026 (StepSecurity); attribution June 19, 2026 (Microsoft)
Malicious dependency	`easy-day-js` (typosquat of `dayjs`); bait `1.11.21`, weaponized `1.11.22`
Mechanism	Obfuscated `postinstall` dropper (`setup.cjs`) → second-stage cross-platform RAT
Access vector	Dormant former-contributor npm credential (scope never revoked)
Scope	140+ packages; 1.1M+ combined weekly downloads
Payload targets	LLM API keys, cloud credentials, environment variables, CI/CD tokens, 166 crypto-wallet extensions
Attribution	Sapphire Sleet (North Korea), per Microsoft
CVE	N/A — supply-chain compromise; this is an execution-control problem

Technical Analysis

How the Attack Works

Per StepSecurity and Microsoft: (StepSecurity) (Microsoft)

Credential abuse. A 16-month-old dormant contributor account — whose scope permissions npm never expired — was used to publish across @mastra (MITRE ATT&CK T1078, T1195.002).
Credibility seeding. A clean [email protected] was published first to look legitimate, then weaponized as 1.11.22.
Mass republish. 140+ @mastra packages were republished with easy-day-js added as a dependency in ~88 minutes.
Install-time execution. On npm install, easy-day-js's postinstall runs node setup.cjs (T1059) — it disables TLS verification, writes a beacon marker to the temp directory, and fetches a second-stage payload from C2 (T1105).
Detached payload + cleanup. The payload is spawned as a detached background process, and setup.cjs self-deletes to remove forensic evidence (T1070).
Theft and persistence. The cross-platform RAT installs OS-level persistence on Windows, macOS, and Linux and harvests LLM API keys, cloud credentials, and crypto-wallet data (T1555, T1552, T1547).

Attack Chain

Trusted AI framework dependency update
      ↓
Compromised @mastra package version
      ↓
Injected dependency: easy-day-js (dayjs typosquat)
      ↓
npm install triggers postinstall script (setup.cjs)
      ↓
Downloader/dropper retrieves second-stage payload from C2
      ↓
Payload executes (detached process) → self-delete
      ↓
Secrets, wallets, tokens, cloud keys, and CI/CD credentials at risk

Payload and Impact

Because developer machines and CI runners typically operate with broad access to source code and secrets, install-time code execution is unusually dangerous: a single npm install can expose API keys, cloud credentials, environment variables, and CI/CD tokens within seconds. The self-deleting dropper and cross-platform RAT make after-the-fact cleanup harder and widen the blast radius across Windows, macOS, and Linux build environments.

Why Traditional Defenses Struggle

The selected package looked clean. The malicious logic arrived through a dependency, not embedded in each @mastra package.
postinstall runs as routine. Install hooks execute automatically during normal package installation — no user "launch" required.
Reputation and name checks miss it. An allowlist based on package name or ecosystem reputation does not catch a malicious child process spawned by node.
Signatures lag. A new, obfuscated, or renamed payload may evade signature-based or behavior-delayed detection — and secrets theft happens fast once code runs.

How White Cloud Security Trust Lockdown Stops This

WCS Trust Lockdown enforces Default-Deny Zero-Trust Application Control: only explicitly Permitted software executes, and unknown software is denied by default. WCS controls what is allowed to execute, not what is merely present on disk.

The control point: execution, not prediction

WCS does not need to predict that easy-day-js is malicious, and it does not need to wait for a malware signature. If the second-stage payload — a downloader, shell script, PowerShell invocation, Node child process, or dropped binary — was not already Permitted by policy, WCS blocks unauthorized execution.

If the malicious dependency tries to spawn a new unauthorized process, the child process is Denied.
If it drops a new file and tries to run it, the dropped file is Denied.
If it renames the file, changes its path, or launches from a temp/cache/npm directory, WCS still evaluates the executable's identity against policy.
WCS uses file handprints — deterministic identity from SHA-1, SHA-256, SHA-512, MD5, CRC32, and file length — instead of trusting a filename, location, or package reputation alone.

Even if the dependency was deployed

This is the central point. Even if a developer or CI runner already downloaded the poisoned package, and even if easy-day-js and setup.cjs exist on disk, WCS prevents the attack from reaching the damaging execution stage unless the payload was explicitly Permitted.

Presence is not permission. Installation is not authorization. With WCS, software must be explicitly permitted before it can execute.

Malicious payloads cannot run merely because a trusted package manager delivered them. That is why software supply-chain attacks are execution-control problems, not just detection problems.

At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of its immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups.

What WCS Would Block

Attack behavior	Why it matters	WCS result
Malicious `postinstall` launches an unauthorized downloader	Install hooks run automatically with developer/CI privileges	Unapproved downloader process is Denied
Downloader drops a second-stage payload	The real damage is in stage two	The dropped, unapproved binary is Denied at launch
Payload executes from npm cache / temp directory	Attackers favor user-writable, low-suspicion paths	Execution from those paths is Denied unless Permitted
Payload renames itself to look benign	Defeats name-based allow rules	Handprint identity still Denies the unapproved file
Payload runs credential-theft tooling	Secrets, keys, and wallets are the objective	Unapproved tooling is Denied before it can harvest
Payload attempts persistence / follow-on execution	Establishes a durable foothold	Unapproved persistence binaries/scripts are Denied

Default-Deny vs. Conventional Defenses

Traditional approach	WCS approach
Trusts known package ecosystems	Enforces Default-Deny at execution time
Scans for known malicious packages	Controls unknown and unauthorized child processes
Looks for indicators after disclosure	Blocks newly dropped binaries and scripts
Relies on EDR detection after behavior begins	Reduces dependency on malware signatures
May grant npm/node/shell/CI runners broad execution rights	Protects developer and build environments from unapproved runtime behavior

To be precise about scope: WCS would not have stopped the npm account takeover, would not have prevented a developer from downloading the poisoned dependency, and would not have flagged easy-day-js as malicious before researchers did. WCS adds a deterministic execution-control layer that blocks unauthorized payloads even when they arrive through trusted software channels — reducing the blast radius of supply-chain compromise. It complements SCA, SBOMs, package-locking, MFA, npm provenance, secret scanning, and CI/CD hardening; it does not replace them.

Recommended Mitigations

Deploy Default-Deny application control on developer laptops, build servers, and CI/CD runners (GitHub Actions, Jenkins, GitLab runners, internal mirrors).
Permit trusted parents, not arbitrary children. Permit known dev tools (Node.js, npm, Git, IDEs, approved build tooling) — but do not auto-permit every child process, downloaded binary, temp-file executable, or script they launch.
Lock down CI/CD runners to approved tools and known build outputs; review and Permit only required build actions.
Audit npm/SaaS access: revoke stale contributor/scope credentials and enforce MFA and provenance on publishing paths.
Pin and verify dependencies (lockfiles, SCA, SBOMs) and consider disabling install scripts (npm ci --ignore-scripts) where feasible.
Rotate exposed secrets (LLM API keys, cloud credentials, CI/CD tokens, wallets) if affected @mastra packages were installed.

Indicators of Compromise

Source: StepSecurity / Microsoft. Treat IOCs as a complement to execution control, not a substitute. (StepSecurity) (Microsoft)

Indicator	Type
`easy-day-js` (bait `1.11.21`, malicious `1.11.22`)	Malicious npm dependency
`setup.cjs` (postinstall dropper, ~4,572 bytes)	File
`<tmpdir>/.pkg_history`	Beacon marker
`23.254.164.92:8000`	Stage-1 C2
`https://23.254.164.92:8000/update/49890878`	Payload URL
`23.254.164.123:443`	Stage-2 C2
npm publisher `sergey2016` (`[email protected]`)	Attacker account
`NODE_TLS_REJECT_UNAUTHORIZED=0` set at install	Behavior

Key Takeaways

"Trusted source" does not mean "trusted execution." A legitimate framework delivered a malicious dependency.
Installation does not equal authorization. Default-Deny stops the payload at the point damage begins — execution.
Handprint identity denies renamed, relocated, or rebuilt payloads that defeat name- and reputation-based rules.
WCS reduces the blast radius of supply-chain compromise and complements SCA, SBOMs, lockfiles, MFA, and CI/CD hardening.