easy-day-js npm Campaign Targets Mastra as Malicious Dependency Attacks Grow
By Sonatype Security Research Team
5 minute read time
TL;DR
-
On June 17, 2026, security researchers identified a software supply chain attack involving the npm package easy-day-js, a malicious package designed to impersonate the popular JavaScript date library dayjs. Sonatype is tracking this campaign as sonatype-2026-003926.
-
Attackers compromised part of the Mastra AI framework and added easy-day-js as a dependency across a large number of Mastra packages. Once installed, the package used a postinstall script to attempt to download and run a second-stage payload from attacker-controlled infrastructure.
-
This is not a "remove the package and move on" incident. If easy-day-js was installed in a developer workstation, CI runner, build agent, or production-adjacent environment, the host should be treated as compromised until investigated.
-
This campaign also extends a pattern Sonatype researchers tracked in the Axios compromise and Atomic Arch campaign. Attackers are not only publishing malicious packages. They are hijacking trusted packages and using malicious dependencies as the delivery mechanism.
Attackers compromised part of the Mastra npm publishing workflow and used that access to add easy-day-js as a dependency across affected Mastra packages.
The malicious code did not live directly in the Mastra package source but inside the dependency those packages were updated to install.
Sonatype is tracking this trend. In the Axios compromise, attackers introduced a hidden malicious dependency into a trusted npm package. In Atomic Arch, attackers took over orphaned Arch User Repository (AUR) packages and modified build instructions to install a malicious npm dependency.
In the Mastra campaign, attackers again used an otherwise trusted ecosystem to pull in a dependency that carried the payload.
How Did the easy-day-js Dependency Attack Work?
The easy-day-js attack worked by adding a malicious dependency to compromised Mastra packages, causing installs of those packages to also install and execute easy-day-js.
The sequence worked like this:
-
The attacker published easy-day-js, a package designed to resemble the legitimate dayjs library.
-
They used an earlier version as a credibility-building or dependency-anchor release.
-
They then published a later version with malicious installation behavior.
-
Compromised Mastra packages added easy-day-js as a dependency.
-
During installation, npm resolved that dependency to the newer malicious version.
-
Once installed, easy-day-js executed through a postinstall hook.
Postinstall scripts run automatically after npm installs a package. Developers use them for legitimate setup tasks, but attackers also use them because they execute while developers and CI systems assemble software.
The application does not need to import the package. Installation is enough.
Why Are Attackers Adding Malicious Dependencies to Trusted Packages?
Attackers add malicious dependencies to trusted packages because the sinister tactic hides inside normal package behavior.
Developers may trust the top-level package, but the risk enters one layer down. A dependency change can look minor in a manifest while still triggering install-time execution, remote payload delivery, and credential exposure.
The pattern also scales. Once attackers compromise a trusted publishing workflow, every downstream install can become a delivery path. The question is no longer just whether someone installed a malicious package. It is whether a trusted package brought one in for them.
What Should Organizations Do If easy-day-js Was Installed?
Organizations should first determine whether easy-day-js only appeared in dependency metadata or actually installed and executed in an environment.
If the package was installed, treat the affected host as compromised. From there:
-
Remove easy-day-js from manifests and lockfiles.
-
Regenerate lockfiles from known-good versions.
-
Reinstall dependencies only after confirming the affected Mastra packages have been remediated or replaced.
-
Investigate developer workstations, build machines, CI runners, and containers where install scripts were allowed to execute.
-
Look for suspicious Node.js processes, unexpected files in temporary directories, outbound connections to known attacker infrastructure, and persistence mechanisms.
Most importantly: Rotate any secrets that may have been present on affected systems. Rotate credentials after investigating for persistence so attackers are not handed new keys on a still-compromised host.
The reason we are still hearing about the Trivy/litellm breach and the axios compromise are because they worked. Stolen credentials from incidents like these are continuously being used to increase the blast radius.
Why Does the easy-day-js Campaign Matter for Dependency Security?
The easy-day-js campaign shows how a small dependency change can create an install-time compromise across a trusted package ecosystem.
Developers and security teams need to watch the dependency layer, not just the top-level package. In the Axios compromise, Atomic Arch, and now the Mastra easy-day-js campaign, attackers used trusted package ecosystems to distribute malicious dependencies.
For affected teams, the priority is not only removing the package. Teams need to determine where easy-day-js was installed, what ran on those systems, and which credentials may have been exposed.
Longer term, teams should enforce policy earlier in development so known malicious packages and suspicious component behavior can be blocked before they reach the build.
Written by Sonatype Security Research Team
Sonatype's Security Research Team is focused on bringing real-time, in-depth intelligence and actionable information about open source and third party vulnerabilities to Sonatype customers.
Explore All Posts by Sonatype Security Research TeamTags
