NPM supply chain attack exposes dependency trust and maintainer risk

At a glance

What this is: This is ArmorCode’s analysis of the September 2025 NPM supply chain attack, which shows how phishing, maintainer account compromise, and malicious package publishing combined into a broad JavaScript ecosystem incident.

Why it matters: It matters because dependency trust, maintainer identity, and package integrity now sit alongside traditional IAM and NHI governance concerns in software delivery.

By the numbers:

• 27 packages are now confirmed compromised, mpromised, affecting billions of weekly downloads across the JavaScript ecosystem.
• The attack began on September 8, 2025, after attackers registered the malicious domain npmjs.help just three days earlier.
• The injected malware maintained over 280 hardcoded attacker addresses for redundancy.

👉 Read ArmorCode's analysis of the September 2025 NPM supply chain attack

Context

NPM supply chain attacks are an identity and trust problem as much as a code integrity problem. When maintainers can be phished into handing over access, attackers inherit the ability to publish malicious versions into a trusted dependency graph, and downstream teams often discover the compromise only after packages are already propagating through builds and browsers.

For IAM and NHI practitioners, the relevant lesson is that maintainer accounts, publishing tokens, and package registry access behave like high-value identities. The incident also shows why software supply chain controls need stronger verification, short-lived access, and lifecycle governance for credentials and third-party publishing rights.

Key questions

Q: What fails when a package maintainer account is phished?

A: The failure is publisher trust, not just endpoint security. Once a maintainer account is compromised, the attacker can publish malicious updates through a trusted distribution channel and reach downstream builds without exploiting application code directly. That is why package publishing should be governed like a privileged identity path, with strong authentication, narrow roles, and rapid revocation.

Q: Why do account takeover metrics matter to IAM and NHI teams?

A: They show how authentication fails in the real world, especially where credentials are reused, leaked, or abused at scale. For IAM and NHI teams, those signals help connect detection to action: rotate exposed secrets, revoke stale access, and review privilege assumptions before a compromise spreads.

Q: How do security teams know if dependency controls are actually working?

A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach. If packages can change quietly and still access sensitive material, the control model is failing even if scans are passing.

Q: Who is accountable when a malicious package reaches production systems?

A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.

Technical breakdown

How phishing turns maintainer access into package compromise

The entry point here was social engineering, not code exploitation. Attackers registered a lookalike domain and sent urgent messages that mimicked registry support, creating a believable path to credential capture or session hijack. Once a maintainer account is compromised, the attacker does not need to break the registry. They can publish trojanised packages, alter versions, and abuse the trust relationship that developers place in the package ecosystem. In identity terms, the account is the control plane. If that identity is weakly verified, the entire dependency chain becomes vulnerable.

Practical implication: protect maintainer identities with phishing-resistant authentication and out-of-band verification for publishing changes.

Why browser-only malware still matters to enterprise builds

The malware in this case executed in browser contexts and targeted payment and wallet-related objects such as window.ethereum, fetch, and XMLHttpRequest. That means the payload was designed to intercept high-value transaction data where it is most useful to the attacker. Even though server-side Node.js workloads were not the primary execution target, the package compromise still contaminated the software supply chain because dependencies can carry malicious logic into many downstream applications. The technical lesson is that package provenance and runtime behaviour both matter.

Practical implication: validate package provenance and inspect dependency behaviour, not just static signatures or version numbers.

Why dependency pinning and integrity checks are only partial controls

Strict version pinning and hash verification help, but they do not eliminate the trust problem when the upstream package itself is compromised before distribution. The article’s package list shows that some versions had to be upgraded while others had to be reverted, which complicates automated remediation. This is where software bill of materials data, staged rollouts, and continuous monitoring become necessary. A dependency control that only records what is installed is not enough if it cannot tell you whether the package behaviour changed after publication.

Practical implication: combine SBOM visibility with runtime monitoring and release gating for any dependency that can alter authentication, payment, or data paths.

Threat narrative

Attacker objective: The attackers aimed to turn trusted package publishing into a distribution channel for credential theft and transaction hijacking at scale.

1. Entry occurred through a phishing campaign that used a lookalike npm support domain to target maintainers and capture access.
2. Credential access followed when compromised maintainer identities were used to publish malicious package versions into the registry.
3. Impact emerged as billions of downstream downloads inherited tainted dependencies, with browser-targeting malware intercepting transactions and wallet activity.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Dependency publishing is now an identity governance problem. The NPM incident shows that package maintainer accounts, publishing tokens, and registry access have the same governance significance as privileged administrative identities. When a maintainer is phished, the attacker inherits trusted publishing rights and can weaponise the dependency graph. That means IAM teams and software supply chain owners need shared lifecycle controls for high-risk publishing identities.

Maintainer trust without phishing-resistant verification creates a standing compromise window. The attack succeeded because urgency and impersonation were enough to bypass human scrutiny. That is a governance failure, not just a user mistake. Organisations that treat maintainers as ordinary users miss the fact that these identities can directly alter production software at scale.

Trust-on-publish debt: this is the specific failure mode exposed here, where dependency ecosystems assume published packages are trustworthy unless proven otherwise. In reality, a single compromised maintainer identity can infect multiple versions before detection catches up. Practitioners should treat package publishing as a privileged workflow with monitored approvals, not a routine developer action.

Security teams need dependency provenance plus identity assurance, not either one alone. Static scanning, signature checks, and version pinning help, but they do not stop a legitimate identity from publishing malicious content. The stronger model combines verified maintainer identity, release gating, and downstream behavioural monitoring. The practical conclusion is that software supply chain governance must extend into identity assurance.

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.
• Forward view: The same research shows organisations maintain an average of 6 distinct secrets manager instances, a fragmentation pattern that strengthens the case for unified lifecycle governance, as discussed in The State of Secrets in AppSec.

What this signals

Identity assurance is becoming a supply chain control, not a separate IAM concern. As package ecosystems depend on maintainer trust, teams should expect more attacks that target publishing identities instead of application code. The governance response is to treat registry access, signing rights, and recovery procedures as privileged workflows with explicit owners and auditability.

Secrets sprawl and publishing trust failures are converging. Our research shows the average estimated time to remediate a leaked secret is 27 days, which is too slow for an ecosystem where malicious packages can spread quickly through trusted dependency paths. That gap strengthens the case for lifecycle controls that combine detection, rotation, and enforcement.

Enterprise programmes should align dependency governance with NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 where tokens, package automation, and publishing identities overlap. The practical signal is clear: if your software supply chain depends on identities that cannot be rapidly verified, revoked, and reissued, you have a resilience gap.

For practitioners

• Harden maintainer publishing identities Require phishing-resistant MFA, separate administrative accounts, and out-of-band verification for package publishing and token resets. Treat registry access as privileged access rather than standard developer access.
• Inventory and prioritise exposed dependencies Use SBOM data to map which internal applications consume the affected packages, then rank remediation by internet exposure, transaction paths, and business criticality.
• Validate package provenance before deployment Check signatures, hashes, and publication history for critical dependencies, and block installs when package ownership or release patterns change unexpectedly.
• Add behavioural monitoring for dependency anomalies Alert on unexpected network calls, browser API interception patterns, or code changes in dependencies that touch authentication, payment, or data transfer paths.

Key takeaways

• The incident shows that a phished maintainer identity can become a software distribution compromise, not just an account takeover.
• The scale matters because at least 27 packages were confirmed compromised and the affected ecosystem spans billions of weekly downloads.
• The control gap is strongest where publishing rights, provenance checks, and downstream monitoring are treated as separate problems instead of one governance surface.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Maintainer Identity: A maintainer identity is the human account that can publish, update, or revoke software packages. In supply chain attacks, that account is often the real target because it controls distribution trust. Protecting it means strong authentication, tight role separation, and rapid revocation when compromise is suspected.
• Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.
• Legacy publishing token: A long-lived authentication credential used to publish or manage packages in a repository. In NHI governance, the risk is not only theft but persistence, because an unrevised token can remain valid after newer controls are added and can bypass the intended identity path.

What's in the full article

ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:

• Package-by-package remediation guidance showing which versions must be upgraded and which must be reverted.
• The complete timeline of the compromise, including the malicious domain registration and the progression of package discovery.
• Code-level malware behaviour analysis, including browser API interception and address replacement logic.
• Detailed dependency list and fix mapping for teams that need to validate their own build pipelines.

👉 ArmorCode's full post covers the affected package list, remediation actions, and malware behaviour in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security and identity teams build the governance habits needed to manage high-risk access across modern programmes.