Mastra npm supply chain attack exposes secrets at install time

At a glance

What this is: A supply chain compromise of the @mastra/* npm scope used a hijacked contributor account and malicious install-time code to steal secrets and persist on affected systems.

Why it matters: It matters because developer workstations and CI runners now sit inside the identity perimeter, so NHI, secrets, and workload controls must cover package trust, publishing access, and credential rotation.

By the numbers:

• The highest-impact package is @mastra/core with approximately 918K weekly downloads.
• The attacker executed an 88-minute automated campaign from 01:12 to 02:39 UTC.

👉 Read Orca Security's analysis of the Mastra npm supply chain attack

Context

The core problem is not just malicious code in a package. It is the trust placed in npm publishing rights, semver-driven dependency resolution, and install-time scripts that execute before defenders can inspect what changed. In identity terms, this is a non-human identity failure: a contributor account retained access long after its publishing authority should have been removed.

For teams running AI application stacks, the attack path matters because package installation often happens in developer laptops, CI runners, and build containers that also hold cloud tokens, GitHub credentials, LLM API keys, and other secrets. When a package update can trigger code execution automatically, the boundary between software supply chain security and NHI governance disappears.

The article describes a typical high-impact supply chain compromise pattern, but the blast radius is wider than a single library. The combination of publishing access, dependency trust, and cross-platform persistence is exactly what makes these incidents operationally urgent for IAM, PAM, and secrets management teams.

Key questions

Q: What breaks when a malicious npm package can run install-time scripts on developer machines?

A: Install-time scripts turn dependency installation into an execution event, which means a package update can steal credentials, alter TLS behaviour, stage a second payload, and plant persistence before most controls see the change. The practical failure is that build and endpoint trust are treated separately even though the package now crosses both boundaries.

Q: Why do stale package publishing rights increase supply chain risk so much?

A: Stale publishing rights let a compromised or former contributor publish malicious releases inside a trusted scope, which makes version numbers and semver ranges part of the attack path. That is why package publisher access must be managed like any other privileged non-human identity with explicit lifecycle review and revocation.

Q: How do security teams know whether developer endpoints are leaking NHI secrets?

A: Look for unexpected token use, unusual outbound connections, unexplained browser profile access, and persistence mechanisms on workstations and build runners. If a compromised package executed on the machine, assume cloud keys, CI secrets, and other non-human credentials may already be exposed and rotate them before restoring trust.

Q: Who is accountable when a package repository compromise exposes enterprise credentials?

A: Accountability sits with the teams that own publishing access, dependency governance, secrets management, and endpoint containment. Frameworks such as OWASP NHI and NIST CSF matter because the failure is not only malware execution, but the absence of lifecycle control over the identities and secrets that the pipeline depended on.

Technical breakdown

Hijacked package publishing access and semver trust

The attack started with a contributor account that still had the right to publish to the @mastra scope. The attacker first published a clean version of easy-day-js and then replaced it with a malicious release, exploiting the fact that dependency ranges such as ^1.11.21 automatically accept newer compatible versions. That means package consumers trusted version metadata, not package intent. In practice, the compromise used legitimate publishing pathways to smuggle malicious code into normal installs, which is why package governance and publisher access reviews matter as much as malware detection.

Practical implication: remove stale publishing access and review package-scope permissions as an identity control, not just a DevOps setting.

Install-time script execution and payload staging

The malicious package used a postinstall hook, which runs during npm install, to disable TLS verification, create local markers, fetch a second-stage payload, start it in the background, and then self-delete. This is a classic supply chain pattern because the initial package does not need to contain every malicious function. Instead, it only needs to trigger code execution at install time and hand off to external infrastructure. The technical risk is that standard dependency approval processes often focus on source provenance while ignoring what install scripts are allowed to do on the endpoint.

Practical implication: block or inspect install scripts in build pipelines and treat postinstall execution as a high-risk privilege.

Cross-platform secret theft and persistence

Once executed, the payload targeted browser data, wallet extensions, and host-level persistence on Windows, macOS, and Linux. That combination turns a package install into credential harvesting, crypto theft, and long-lived foothold creation. The persistence paths listed in the article show that the attacker was not only after immediate exfiltration but also future access to the workstation and adjacent cloud services. For identity teams, this is important because a compromised developer endpoint can expose NHI secrets that were never meant to leave the build boundary.

Practical implication: rotate all secrets on exposed developer and CI systems, then hunt for persistence on every supported operating system.

Threat narrative

Attacker objective: The attacker aimed to convert trusted package installs into durable access for stealing secrets, hijacking wallets, and maintaining persistence across compromised development systems.

1. Entry occurred when attackers republished trusted @mastra/* packages through a hijacked npm contributor account and dependency ranges pulled the malicious version automatically.
2. Escalation followed when the malicious install script executed during npm install, staged a second payload, disabled TLS verification, and established detached background persistence.
3. Impact included credential theft, cryptocurrency wallet compromise, host reconnaissance, and exfiltration of secrets from developer machines and CI environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package publishing access is a non-human identity control, not a software release convenience. This attack worked because publishing authority outlived the trust that granted it. In NHI terms, the contributor account remained a standing identity with the power to ship code into a widely consumed scope, which turned package publishing into a privileged access path. The practitioner implication is that npm publisher lifecycle management belongs in the same governance conversation as service account review and PAM.

Install-time execution creates a secrets exposure window that normal code review does not cover. The malicious dependency did not need to be universally sophisticated because the install hook executed before most organisations could inspect behaviour in context. That means the governance gap is not only malicious code, but the assumption that dependency installation is a passive act. Practitioners must treat build-time execution as an identity-sensitive event with access to tokens, credentials, and environment state.

Cross-platform persistence turns a developer endpoint into an NHI blast-radius problem. The payload was built to survive across Windows, macOS, and Linux, which means the compromise was targeting the identity material on the machine rather than a single application. This is the kind of lateral risk NHI governance often misses when it focuses on central vaults but not on endpoints that cache secrets and session material. The implication is that endpoint control and secrets control must be designed together, not separately.

Credential scope and package scope now intersect in ways that break old assumptions about least privilege. Least privilege was designed for a world where publishing access, runtime execution, and secret access were more separable than they are in modern developer pipelines. That assumption fails when a single package update can reach cloud keys, LLM tokens, browser sessions, and wallet extensions inside one install event. Practitioners need to rethink where privilege actually resides in the software supply chain.

Supply chain compromise is now an identity lifecycle problem for machine access. Revocation, offboarding, and token rotation are no longer just responses to account compromise after the fact. They are the controls that determine whether stale publishing rights, stale CI secrets, and stale environment credentials can be converted into enterprise-wide exposure. Teams should map package publisher lifecycle to the same governance model used for other privileged non-human identities.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• For broader NHI breach patterns and control failures, see 52 NHI Breaches Analysis for how stale access and secret exposure become repeatable compromise paths.

What this signals

Ephemeral trust debt: package installs, CI runs, and developer laptops now create a short but high-value window in which secrets can be harvested before defenders can react. That window is exactly where modern supply chain attacks win, which is why build telemetry and endpoint identity controls need to be considered together rather than as separate programmes.

With 43% of security professionals already concerned about AI systems learning and reproducing sensitive information patterns from codebases, the issue is no longer limited to one compromised package or one repository. The programme implication is to treat code, secrets, and machine identity as one control plane, then anchor that approach in the OWASP Non-Human Identity Top 10.

Teams that still treat npm publishing and CI credentials as engineering concerns rather than identity events will keep missing the same failure mode. A package-scope compromise is not just supply chain noise, it is a lifecycle failure in privileged machine access, and it deserves the same governance cadence as service account review.

For practitioners

• Audit package publishing rights and revoke stale contributors Review every npm scope and package owner list for abandoned or unnecessary publishing access, especially contributor accounts that no longer match current operational ownership. Tie package-scope access to joiner-mover-leaver processes so publishing rights are removed when roles change.
• Inspect build pipelines for install-script execution Identify where npm install runs with script execution enabled in developer laptops, CI runners, and container builds. Quarantine or inspect postinstall behaviour for packages that can fetch remote payloads, change TLS settings, or create background persistence.
• Rotate exposed secrets across all affected systems Treat any machine that installed the compromised packages as exposed and rotate npm tokens, GitHub tokens, cloud provider keys, LLM API keys, CI/CD secrets, SSH keys, database credentials, and wallet material created or cached on those endpoints.
• Hunt for persistence on developer endpoints and runners Check Windows Run keys, macOS LaunchAgents, Linux user services, and NodePackages directories for the persistence artefacts named in the disclosure. Correlate those findings with suspicious outbound traffic to the listed infrastructure before returning systems to service.

Key takeaways

• This attack shows that trusted package publishing and install-time execution can be converted into credential theft, persistence, and exfiltration in one workflow.
• The scale is material, with more than 1.1 million weekly downloads across Mastra packages and 918K weekly downloads for the top package alone.
• The limiting controls are identity lifecycle, script execution governance, and secret rotation across every affected developer and CI environment.

Key terms

• Supply Chain Identity Risk: Supply chain identity risk is the exposure created when trusted software delivery paths are controlled by identities that can publish, update, or execute code. In practice, it includes package owners, CI tokens, build runners, and install-time scripts that can turn routine software handling into privileged access.
• Install-Time Execution: Install-time execution is code that runs automatically when a package is installed, before the application itself starts. For identity governance, it is risky because the installer can access local secrets, modify host settings, fetch second-stage payloads, and persist on the endpoint without separate approval.
• Publisher Lifecycle Management: Publisher lifecycle management is the process of granting, reviewing, and revoking package publishing authority for non-human identities. It matters because stale publishing access can survive role changes, allowing old credentials or hijacked contributor accounts to push malicious versions into a trusted scope.
• Secrets Exposure Window: A secrets exposure window is the period during which credentials, tokens, or keys are accessible to malicious code before defenders can detect and rotate them. In developer and CI environments, that window can be very short, which makes detection speed and revocation discipline critical controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: Mastra npm supply chain attack and install-time secret theft. Read the original.