NPM supply chain attacks show how phishing scales into production

At a glance

What this is: This is Aqua Security's analysis of a phishing-driven NPM supply chain attack that used a stolen maintainer credential to push malware into 18 popular packages.

Why it matters: It matters because software supply chain compromise now depends on identity and secret hygiene as much as code review, affecting NHI, autonomous pipeline, and human access governance.

By the numbers:

• 18 high-profile npm packages were tainted in the attack.
• A security firm flagged the suspicious updates at about 13:16 UTC on September 8, 2025.

👉 Read Aqua Security's analysis of the NPM supply chain hijack

Context

Software supply chain attacks increasingly begin with identity compromise, not code exploitation. In this case, a phishing message captured a maintainer credential, which then became the entry point for malicious package publishing across the NPM ecosystem.

For IAM, PAM, and NHI programmes, the lesson is that registry trust is only as strong as the identity path behind it. When a human maintainer account is stolen, the downstream effect looks like NHI risk, because signed builds, package pipelines, and production workloads all inherit that compromised trust state.

Key questions

Q: How should security teams reduce supply chain risk from compromised package maintainers?

A: Start with maintainer identity assurance. Require phishing-resistant MFA, enforce least-privilege publishing roles, and review who can release packages on behalf of the project. Then add detection for suspicious login behaviour, because registry compromise usually begins with account abuse rather than code defects.

Q: Why do compromised open-source packages create such a large blast radius?

A: Because downstream consumers inherit trust in the publisher, not just the code. A single tainted package can flow into many direct and transitive dependencies, CI/CD builds, container images, and production workloads. The real risk is distribution scale combined with weak visibility into dependency paths.

Q: What do teams get wrong about scanning dependencies for malware?

A: They often assume source scanning alone is enough. In practice, malicious code may look benign until it runs, especially when it hides in a package that alters browser requests or network behaviour at execution time. Behavioural analysis and runtime monitoring are needed to catch that class of abuse.

Q: Who is accountable when a stolen maintainer account pushes malicious packages?

A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.

Technical breakdown

Phishing to maintainer credential theft

The attack began with a lookalike domain and a fake 2FA warning, which are classic social engineering techniques aimed at account takeover. Once the maintainer submitted credentials, the attacker no longer needed a software flaw in the package ecosystem. They had valid access to the publishing channel, which is the real control plane for open-source distribution. In supply chain terms, the compromise was not the package itself, but the identity used to publish it. That distinction matters because repository trust, signing, and build integrity all assume the publisher identity is authentic and uncompromised.

Practical implication: protect maintainer identities with phishing-resistant authentication and separate publishing rights from day-to-day access.

Malicious package publication and blast radius

After credential theft, the attacker rapidly published tainted versions of 18 widely used packages. That created a high-velocity propagation path into downstream builds, CI/CD systems, container images, and production dependencies. The risk is not only direct installation. Transitive dependency chains mean teams often consume compromised packages indirectly, which expands the blast radius far beyond the original maintainer account. In this model, the supply chain becomes an identity distribution system: if one publishing identity is abused, every consumer of that package inherits the risk until the malicious version is removed or pinned out.

Practical implication: maintain software bill of materials coverage and package allowlisting so compromised dependencies can be identified and blocked quickly.

Browser-based interceptor payloads in developer ecosystems

The injected code acted as a browser-based interceptor that targeted cryptocurrency and Web3 activity by manipulating network requests and redirecting funds. That is a different failure mode from a simple backdoor. The malware sat in the application path and altered transaction behaviour at runtime, which makes static inspection alone insufficient. This pattern shows why supply chain defence has to extend beyond package integrity into runtime behavioural analysis. A dependency can look harmless in source form and still become dangerous only when executed in the browser or application context.

Practical implication: detonate suspicious dependencies in sandboxed analysis before release and monitor runtime traffic for abnormal request manipulation.

Threat narrative

Attacker objective: The attacker aimed to compromise transaction flows by inserting browser-side malware into widely consumed packages and diverting crypto or Web3 funds to attacker-controlled accounts.

1. Entry occurred through a phishing email sent from a lookalike domain that tricked the maintainer into submitting credentials on a fake login page.
2. Escalation happened when the attacker used the stolen publishing access to push malicious versions of 18 popular NPM packages into the registry.
3. Impact followed through downstream builds and applications that pulled the tainted packages, creating a route for transaction interception and fund redirection.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

Identity compromise is now the front door to supply chain compromise. This attack did not start with a software vulnerability in NPM. It started with a stolen maintainer identity, which turned publishing access into an ecosystem-scale distribution channel for malware. That is the decisive governance shift: software trust is no longer separable from identity assurance, especially where maintainers can push code that reaches millions of downstream systems. Practitioners should treat maintainer authentication as a supply chain control, not just a user login concern.

Package integrity controls without runtime inspection leave a blind spot. The malicious payload only became operational when executed in the target environment, where it could intercept browser requests and alter transaction flow. That means source scanning alone cannot close the risk. The failure mode is a trust gap between what was reviewed and what actually ran. Security teams need to recognise that modern dependency abuse often survives static review and only becomes visible through behaviour.

Phishing-resistant publishing is a governance requirement, not an optional hardening step. The attacker succeeded because a human maintainer account could be coerced into revealing credentials through a fake 2FA prompt. This is a classic case where the control assumption was that the legitimate publisher would remain the legitimate operator. The implication is that package ecosystems need stronger proof of publisher intent, tighter separation of duties, and explicit lifecycle governance for maintainers who can affect production software.

Supply chain blast radius is an identity problem disguised as a software problem. The headline number here is not just package count, but distribution reach across billions of weekly downloads. When one publishing identity can touch that many downstream consumers, the governing question becomes who can publish, under what assurance, and with what revocation speed. Teams should align registry controls, secret hygiene, and access reviews around publisher identity, not just repository content.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader view of recurring NHI failure patterns, see 52 NHI Breaches Analysis and use it to benchmark your own exposure and lifecycle controls.

What this signals

Package publishing is becoming part of identity governance. The practical boundary between software supply chain security and IAM has collapsed. When a maintainer account can inject malicious code into 18 packages that reach billions of weekly downloads, organisations need lifecycle controls for publishing identities, not just developer access reviews.

Blast-radius visibility now belongs in the dependency programme. Teams that cannot identify where a package lands will not contain a registry compromise quickly enough. Build-time controls, SBOM coverage, and transitive dependency mapping should be treated as programme baselines, not advanced capabilities.

Runtime trust debt: any package approval process that stops at static review leaves a debt that only runtime behaviour can expose. That is where dependency abuse, token theft, and transaction interception become visible, especially in cloud-native systems that auto-ingest updates. Use the OWASP Non-Human Identity Top 10 to tie publisher identity assurance to access scope and release governance.

For practitioners

• Harden maintainer authentication Require phishing-resistant MFA for package publishers, separate publishing credentials from general developer access, and monitor for login attempts from lookalike domains and unusual geo-velocity.
• Restrict package publish authority Limit who can publish to registries, use tightly scoped release roles, and remove standing publishing access for accounts that do not need it every day.
• Use SBOMs to map downstream exposure Track direct and transitive dependencies so a compromised package can be identified across applications, images, and clusters before it reaches production.
• Detonate suspicious dependencies before release Run behavioural analysis on new or updated packages in a sandbox to detect hidden network calls, script injection, and wallet or credential interception logic.
• Add runtime controls for dependency abuse Watch for unexpected package downloads, outbound request manipulation, and suspicious browser or workload egress patterns that indicate malicious dependency execution.

Key takeaways

• This attack shows that a compromised maintainer identity can turn a trusted open-source package into a malware distribution channel.
• The scale was amplified by 18 tainted packages and 2.6 billion weekly downloads, which made the blast radius ecosystem-wide rather than local.
• The limiting control is not just package scanning but publisher identity assurance, transitive dependency visibility, and runtime behavioural detection.

Key terms

• 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.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another package. It matters because compromise can enter your environment without appearing in your direct install list. Security teams need visibility into transitive paths to understand the full blast radius of a poisoned package.
• Behavioural Analysis: Behavioural analysis observes what software does when executed instead of relying only on static code review. It is useful for detecting hidden actions such as network interception, credential theft, or command execution that may not be obvious in source code. In supply chain defence, it closes the gap between review and runtime.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies inside an application or image. It gives security teams a way to locate affected systems quickly when a package is compromised. For supply chain governance, it turns dependency risk into something that can be searched, assessed, and contained.

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 Aqua Security: NPM supply chain threat to cloud-native environments. Read the original.