NPM maintainer account takeover exposed gaps in supply chain trust

At a glance

What this is: StepSecurity’s analysis describes a supply chain attack in which a compromised maintainer account led to malicious NPM releases that stole cryptocurrency wallets and redirected blockchain transactions.

Why it matters: It matters to IAM, PAM, and NHI practitioners because maintainer identities, signing paths, and CI/CD secrets all sit in the trust chain that attackers can exploit to reach production.

By the numbers:

• More than 20 widely used NPM packages were compromised after the maintainer account takeover.
• The attack targeted cryptocurrency users through malicious package versions published on September 8, 2025.

👉 Read StepSecurity’s analysis of the compromised NPM packages and maintainer takeover

Context

Open source package ecosystems fail when identity trust is assumed to be durable across maintainer logins, release actions, and downstream builds. In this case, a phishing email was enough to move from account access to malicious package publication, which is the kind of failure that appears technical but is really governance-bound. The primary issue is not package management alone, but the identity and release chain around it.

For identity and application security teams, the relevant lesson is that software supply chain trust now depends on how human identities, secrets, and build-time controls intersect. Maintainer accounts, 2FA reset paths, and CI/CD monitoring can no longer be treated as separate layers because attackers only need one weak link to turn legitimate publishing into a distribution channel for malware.

Key questions

Q: What breaks when a package maintainer account is compromised?

A: When a maintainer account is compromised, the attacker inherits trusted publishing rights and can turn legitimate release channels into malware distribution paths. That breaks the assumption that package provenance is tied to a stable, accountable identity. The result is not just one bad package, but potentially broad downstream exposure across automated build and install pipelines.

Q: Why do maintainer phishing attacks remain so effective against software ecosystems?

A: They succeed because maintainers often have privileged release authority, recovery workflows still depend on email, and teams assume authentication is enough. Once the account is taken over, the attacker inherits trust from the registry and the package name. This makes account recovery design a supply chain security issue, not just a help desk issue.

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: Should organisations treat package maintainers as privileged identities?

A: Yes. Maintainers can change what thousands of downstream systems execute, which is functionally privileged access. They should be governed with the same seriousness as other high-impact roles, including stronger authentication, tighter recovery controls, separation of duties, and rapid revocation when compromise is suspected.

Technical breakdown

Maintainer account takeover as the entry point

The initial compromise here was social engineering, not code execution. Attackers used a phishing email that impersonated a 2FA reset notice, which is effective because many maintainer workflows still rely on email-linked recovery paths and weak human verification. Once the attacker controlled the maintainer identity, they inherited the right to publish packages that downstream systems already trusted. That is why maintainer identity is part of supply chain security, not just access management.

Practical implication: protect maintainer accounts with phishing-resistant authentication and hardened recovery workflows.

Malicious package publication and dependency trust

After account takeover, the attacker published malicious versions of high-download packages that many projects ingest automatically. In package ecosystems, trust is inherited by version number, signer, and registry reputation, so a poisoned release can move faster than human review. The danger is amplified when teams consume new package versions immediately, because the attacker’s window is front-loaded into the first hours after publication. This is a provenance and release-governance failure as much as a malware problem.

Practical implication: add release provenance checks and delayed adoption controls for newly published dependencies.

Runtime interception inside build and user flows

The injected code did not merely sit in a dependency tree. It intercepted browser and network behaviour, detected crypto wallet activity, and rewrote transaction destinations in real time. That pattern matters because modern supply chain attacks often weaponise legitimate execution contexts rather than dropping obvious payloads. Once malicious code runs inside CI/CD or application runtime, traditional package scanning alone is too late; monitoring must observe actual process, file, and network behaviour.

Practical implication: monitor CI/CD and application runtime for anomalous process and network activity tied to dependency execution.

Threat narrative

Attacker objective: The attacker aimed to monetise trusted package distribution by stealing cryptocurrency wallets and redirecting blockchain transactions at scale.

1. Entry occurred through a phishing email that imitated a 2FA reset notification and captured the maintainer account.
2. Escalation followed when the compromised maintainer identity was used to publish malicious versions of widely trusted NPM packages.
3. Impact came through wallet detection and transaction rewriting that redirected cryptocurrency activity to attacker-controlled destinations.

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

Identity in the supply chain is now a release control, not just an account control: this attack worked because the maintainer identity was trusted to publish code into an ecosystem that automates consumption. When a phishing email can convert a human account into a malware delivery mechanism, the control gap is not only authentication but lifecycle governance over who can publish, recover, and delegate release rights. Practitioners should treat maintainer identity as part of the software trust boundary.

Provenance drift is a named concept worth tracking here: the danger is not simply malicious code, but the gap between where a package appears to originate and how it actually entered the ecosystem. That gap widens when teams accept fresh versions immediately, when registry trust is assumed to equal integrity, and when build systems do not validate release history. The practical conclusion is that provenance needs explicit policy, not informal confidence.

Secret exposure and package compromise converge in the same operational failure mode: once malicious dependency code executes, it can reach secrets in developer workstations, CI/CD systems, and browser sessions. That makes secrets governance, identity governance, and software supply chain security one combined control problem. Teams that separate these disciplines will miss the blast radius created when package trust and credential trust collapse together.

Maintainership is a privileged role that deserves PAM-style scrutiny: package maintainers can affect thousands of downstream environments with a single release, which makes their accounts operationally equivalent to high-impact privileged access. The industry has been too comfortable treating maintainers as ordinary users rather than elevated actors with release authority. Security teams should assess whether their own supply chain policies reflect that privilege asymmetry.

The attack reinforces that open source dependency risk is now an NHI governance problem at ecosystem scale: automation, bots, and maintainer accounts all participate in package publishing and consumption paths, and each is a non-human or identity-adjacent control point. OWASP Non-Human Identity Top 10 aligns closely with this pattern because credential handling, rotation, and third-party trust all shape the outcome. The lesson is to govern publish rights, not just scan dependencies after the fact.

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.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
• This fragmentation mirrors package trust sprawl, so teams should also review the 52 NHI breaches Report for repeatable governance failure patterns.

What this signals

Provenance drift is the operational problem teams need to watch next: dependency trust can collapse long before a security tool raises an alert, especially when release systems accept new versions faster than governance can verify them. A useful control pattern is to pair package intake policy with identity controls around maintainers and release administrators, then enforce release-source validation through the OWASP Non-Human Identity Top 10.

The broader signal for security programmes is that software supply chain defence is becoming a hybrid identity and runtime problem. If a maintainer account, CI/CD secret, or package publishing workflow can introduce malicious code, then identity lifecycle, secrets management, and runtime monitoring must be planned together rather than managed by separate teams.

For teams dealing with developer platforms, this incident reinforces that release governance needs evidence, not assumptions. Cooldown periods, provenance checks, and anomaly detection should be tied to policy thresholds so that high-risk package updates are not merely reviewed but operationally constrained before they reach production.

For practitioners

• Harden maintainer recovery paths Require phishing-resistant authentication, restrict email-based 2FA resets, and review who can approve account recovery for package maintainers and release admins.
• Delay adoption of fresh dependency releases Use a cooldown period for newly published package versions so your pipeline does not automatically trust the first hours after release.
• Validate package provenance before build promotion Block or flag dependency updates that do not match expected publish sources, signing patterns, or release timing in your approved pipelines.
• Monitor CI/CD for dependency-driven anomalies Watch for unusual network calls, file modifications, and process execution during builds, especially when a package update coincides with new runtime behaviour.
• Map maintainer roles to privileged access controls Treat high-impact package maintainers like privileged operators by reviewing publish rights, separation of duties, and emergency revocation paths.

Key takeaways

• A maintainer account takeover can turn trusted open source publishing into a malware delivery channel without breaching perimeter defences.
• The scale matters because packages downloaded billions of times weekly can amplify a single phishing success into ecosystem-wide exposure.
• Cooldowns, provenance checks, and privileged maintainer governance are the controls that reduce the blast radius of this failure mode.

Key terms

• Package maintainer identity: The account or credential used to publish and manage software packages in a registry. In practice, this is a privileged operational identity because it can change what downstream systems trust and install. If that identity is hijacked, the attacker can distribute malicious code through a legitimate channel.
• Provenance Drift: Provenance drift is the loss of trust in a data label or access decision after the underlying content or movement path changes. It is a practical governance failure, not a theoretical one. When drift appears, static classification no longer reflects operational reality and enforcement becomes unreliable.
• Cooldown Period: A policy delay that prevents immediate use of newly published dependencies. It gives defenders a short window to detect malicious releases before they are automatically adopted into build and deployment pipelines.
• Release governance: The controls that decide who can publish software, under what approval conditions, and with what revocation path. For non-human identities, release governance is part of identity security because publishing credentials often have production-level impact even when they look like routine developer tools.

What's in the full analysis

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

• The package-by-package compromise list, including exact malicious versions and affected dependency chains.
• Step-by-step recovery commands for npm, yarn, and lockfile inspection across developer environments.
• StepSecurity’s cooldown control logic and how it flags newly released package versions in pull requests.
• Harden-Runner and Artifact Monitor implementation detail for CI/CD runtime and release provenance detection.

👉 StepSecurity’s full post covers the malware behaviour, recovery steps, and CI/CD controls in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle controls. It helps security and identity teams translate governance gaps like this into operating model decisions.