The compromise of 144 npm packages associated with the Mastra AI framework demonstrates how a single overlooked contributor account can create a large-scale software supply-chain incident. The affected packages belonged to the @mastra namespace, which is used by developers building JavaScript and TypeScript artificial intelligence applications. 

The attack reportedly began after threat actors gained control of the npm account of a former Mastra contributor. Although the contributor was no longer actively involved with the project, the account’s permission to publish packages under the Mastra namespace had not been removed.

Using this access, the attacker was able to publish malicious versions of more than 140 packages within a short period. This highlights a common weakness in open-source and software-development environments: organizations carefully manage active employees and contributors but sometimes fail to revoke access when roles change or participation ends.

The compromised Mastra packages did not directly contain the primary malicious code. Instead, the attacker added a new dependency called easy-day-js to the affected packages. This dependency acted as the delivery mechanism for the malware.

The use of a separate malicious dependency made the attack more difficult to detect through a basic review of the Mastra package code. Developers inspecting only the main package changes might have seen what appeared to be an ordinary dependency update, while the actual malicious behaviour remained hidden inside the newly introduced library.

The easy-day-js package was designed to resemble the legitimate and widely used dayjs date-management library. This form of package impersonation relies on developers overlooking small differences in package names, particularly when dependencies are installed automatically through build tools.

The malicious package was initially published as a clean and functional library before being updated with harmful code. This tactic can help attackers establish an apparently legitimate package history and avoid immediate suspicion during its initial publication.

Once the malicious version was installed, easy-day-js executed an obfuscated payload through an npm postinstall script. Postinstall scripts run automatically when a package is installed, allowing the attack to begin even before a developer imports the compromised Mastra library or runs the application.

This is one of the most dangerous aspects of the incident. A developer did not need to actively call a malicious function or execute unfamiliar code. Merely installing the affected package could trigger the attack. Apparently, even downloading dependencies now counts as executing untrusted software, because the ecosystem decided convenience should come with invisible shell access.

The postinstall script disabled TLS certificate verification and downloaded a second-stage payload from attacker-controlled infrastructure. Disabling certificate validation allowed the malware to retrieve files without properly confirming the identity of the remote server.

The downloaded payload was then launched as a detached background process. The loader subsequently attempted to remove itself, reducing the forensic evidence left behind and making it more difficult for developers or security teams to identify the original infection path.

The final payload operated across Windows, macOS, and Linux. This cross-platform capability significantly expanded the potential impact because development teams commonly use a mixture of operating systems across employee workstations, build servers, and CI/CD runners.

The malware was capable of collecting browser history and information from more than 160 cryptocurrency wallet browser extensions. It could also establish persistence and transmit stolen data to attacker-controlled command-and-control infrastructure.

Cryptocurrency wallet extensions are particularly valuable targets because they may contain wallet information, authentication data, session details, or access to financial assets. However, the wider enterprise risk extends far beyond cryptocurrency theft.

Developer systems frequently contain source-code repository credentials, npm tokens, cloud access keys, SSH keys, API credentials, database passwords, AI-service tokens, CI/CD secrets, signing keys, and internal documentation. An information stealer running on such a system may provide attackers with access to multiple parts of the organization.

A compromised developer workstation can therefore become the starting point for repository theft, cloud compromise, unauthorized package publication, intellectual-property loss, or further software supply-chain attacks. Attackers may use stolen credentials from one incident to compromise additional packages, creating a chain of trusted software distribution that spreads the attack to other organizations.

The incident reportedly involved the legitimate account of a former Mastra contributor whose publishing permissions had never been revoked. This demonstrates that identity and access management must extend to open-source registries, package repositories, development tools, and community platforms, not only traditional corporate systems.

Organizations should maintain an accurate inventory of all users and service accounts that can publish packages or modify build pipelines. Access should be reviewed periodically and revoked immediately when a developer, employee, contractor, or contributor no longer requires it.

Package-publishing accounts should use phishing-resistant multi-factor authentication wherever supported. Long-lived npm access tokens should be avoided or restricted, and tokens should be scoped to the minimum packages and operations required.

Mastra’s legitimate releases were normally published through a trusted CI workflow with provenance attestations. However, the project did not enforce provenance as a mandatory requirement, meaning the hijacked contributor account could still publish packages using a standard npm token without the expected attestations.

Software provenance allows consumers to verify where and how a package was built and published. In this incident, the malicious versions reportedly lacked the provenance information normally attached to official Mastra releases.

This difference could have provided an important detection signal. Organizations that enforce signature and provenance verification may have rejected the malicious packages before installation. However, provenance is useful only when it is actually required. Generating attestations for legitimate releases while continuing to accept unattested packages leaves an avoidable gap.

Development teams should configure package-management policies to reject unsigned or unverified releases where practical. CI/CD systems should validate package signatures, build provenance, publisher identity, dependency changes, and integrity hashes before allowing new versions into production workflows.

Organizations should also use dependency-lock files and internal package repositories to reduce uncontrolled installation of newly published versions. Automatically installing the latest package release directly from a public registry can expose systems to malicious updates before security teams have time to evaluate them.

However, lock files are not a complete defence. If a malicious version is added during an approved update or dependency refresh, the compromised package may still become permanently recorded in the application’s dependency tree. Dependency review and continuous monitoring remain necessary.

Any developer workstation, build server, CI runner, or container image that installed an affected Mastra package version should be treated as potentially compromised. The risk begins at installation time because the payload executes through the postinstall mechanism.

Simply uninstalling the affected package or reverting to an earlier version is not sufficient. By the time the malicious dependency is discovered, the information stealer may already have executed, established persistence, and transmitted credentials or other sensitive information.

Potentially affected systems should be isolated and examined for suspicious processes, startup entries, scheduled tasks, modified shell profiles, unfamiliar executables, unexpected network connections, and artifacts associated with the malicious easy-day-js package.

Organizations should rotate credentials that were present on affected systems. This may include source-code repository tokens, npm credentials, cloud keys, SSH keys, CI/CD secrets, API tokens, AI-service keys, database passwords, cryptocurrency wallet credentials, and active browser sessions.

Credential rotation should be performed from a separate trusted system. Changing passwords from the potentially infected workstation may simply provide the malware with the replacement credentials, a wonderfully efficient way to conduct the same breach twice.

Security teams should review repository and cloud audit logs for suspicious activity following installation of the affected packages. Warning signs may include unusual logins, newly generated tokens, unauthorized repository cloning, changes to CI/CD workflows, unexpected package publications, creation of cloud resources, or access from unfamiliar locations.

Npm activity should also be reviewed for unexpected package releases, permission changes, token usage, or access from unknown IP addresses. Organizations maintaining public packages should verify that all existing maintainers and publishers still require access.

Network controls can help detect malicious package behaviour even when the package itself passes initial code review. DNS monitoring, outbound filtering, proxy inspection, intrusion prevention, and threat-intelligence controls can identify unexpected connections from developer systems and CI environments to unfamiliar infrastructure.

CI/CD runners and build systems should not have unrestricted outbound internet access. They should be permitted to communicate only with approved package repositories, source-code platforms, artifact stores, and necessary external services.

Build environments should also use short-lived credentials and isolated execution. A malicious dependency running during installation should not automatically gain access to production secrets, signing keys, deployment credentials, or unrelated cloud environments.

Secrets should only be injected into a build stage when they are specifically required and should be removed immediately afterward. Shared environment variables containing broad, long-lived credentials create a valuable target for any malicious dependency that executes inside the pipeline.

Developers should scrutinize newly added dependencies, particularly packages with names resembling popular libraries. Typosquatting, dependency confusion, abandoned packages, and malicious maintainer updates remain common techniques because modern applications may include hundreds or thousands of indirect dependencies.

Organizations should use software-composition analysis tools to continuously identify vulnerable, malicious, abandoned, or unexpected dependencies. These tools should monitor both direct and transitive dependencies because the malicious component may be several levels removed from the application’s declared package list.

Security teams should also alert on the introduction of install scripts, especially postinstall, preinstall, or prepare scripts in dependencies that previously did not use them. Such scripts may be legitimate, but they deserve additional scrutiny because they execute automatically during package installation.

Where technically possible, package installation scripts should be disabled or restricted in sensitive build environments. Applications that require install-time scripts should be reviewed and explicitly approved rather than allowing every dependency to execute arbitrary commands automatically.

The Mastra incident also demonstrates the security importance of contributor lifecycle management in open-source projects. Publishing access should not remain indefinitely attached to accounts merely because removing it is administratively inconvenient.

Projects should use role-based access, periodic permission reviews, hardware-backed authentication, protected release workflows, and trusted publishing mechanisms. Direct publication using personal tokens should be restricted, particularly for high-download packages.

Package scopes should enforce provenance and trusted-publisher requirements so that releases created outside the approved CI/CD process are rejected automatically. A secure release process should not depend on reviewers noticing that one package version arrived through an unusual account.

The potential scale of this attack is significant because some affected Mastra packages are widely downloaded. The @mastra/core package alone reportedly receives hundreds of thousands of weekly downloads. Even a short exposure window can therefore place many developer systems and automated pipelines at risk.

The incident is especially relevant because Mastra is used to build AI applications. AI-development environments often hold access to model providers, vector databases, cloud platforms, private datasets, automation tools, and external APIs.

Compromise of these environments may expose not only traditional development credentials but also AI API keys, proprietary prompts, model configurations, agent instructions, sensitive datasets, and connected enterprise systems. An attacker who gains access to an AI agent’s development environment may be able to abuse the same tools and permissions intended for automation.

For customers, the key lesson is that software supply-chain security must extend beyond vulnerability scanning. A package may contain no known software vulnerability and still be malicious because an attacker controls its publication process or dependencies.

Organizations must verify who published a package, how it was built, whether its provenance is valid, what dependencies changed, and what actions it performs during installation. Trust cannot be based solely on a familiar package name, download count, or official namespace.

The Mastra compromise demonstrates how one stale contributor account can bypass an otherwise legitimate release process and distribute malware across a widely used package ecosystem. Protecting against similar attacks requires strict access revocation, enforced provenance, controlled dependencies, isolated build environments, continuous monitoring, and rapid credential rotation after exposure.

Software dependencies have become part of the enterprise trust boundary. Every package installed in a developer workstation or CI pipeline is effectively being granted an opportunity to execute inside the organization. Treating that decision as routine administration rather than a security event gives attackers exactly the quiet access they need.

As many as 144 npm packages associated with the Mastra namespace ("@mastra/*"), a popular open-source JavaScript and TypeScript framework for building artificial intelligence (AI) applications, have been compromised as part of a software supply chain attack codenamed easy-day-js, per findings from JFrog, SafeDep, Socket, and StepSecurity. "A single npm account (ehindero) mass-published more

Source: 144 Mastra npm Packages Compromised via Hijacked Contributor Account via The Hacker News — published 17 Jun 2026.