How Attackers Target npm Maintainer Accounts

April 2026

Why npm Maintainer Accounts Are the Most Underprotected Attack Surface in Software Development

For two decades, security thinking moved in a clear direction: from hardening the network perimeter to managing identity. Cloud infrastructure made identity the primary target. npm supply chain attacks have located a third perimeter that most security programmes are not watching at all: the individual developer with publishing rights to packages installed in millions of production environments.

Every npm package has one or more maintainers: the developers who own the publishing credentials for that package and control what versions reach the registry. When those credentials are stolen, transferred, or simply left active after someone's departure, whoever holds them becomes the legitimate publisher from the registry's perspective. No additional verification. No code review. No approval process.

This is not a flaw the registry has failed to fix. It is the fundamental trust model: identity is defined by credential possession, and the security of those credentials sits entirely with the maintainer. For a single developer managing a package installed in 80% of cloud environments, that is a significant concentration of trust in a single account.

Unlike a corporate identity boundary, this perimeter has no SOC monitoring it, no enforced MFA policy, no offboarding checklist, and in most cases no provenance requirement on what gets published. It is the most consequential unmonitored attack surface in modern software development.

npm supply chain attacks of this type do not require a CVE. They require access to one set of maintainer credentials and a registry that treats whoever holds them as the legitimate publisher. The payload design, the evasion technique, the propagation mechanism, those vary by incident. The credential trust gap that makes all of them possible has not changed since 2018.

The Three Entry Points Attackers Use to Gain npm Publishing Rights

Documented attacks on npm maintainer accounts fall into three distinct entry points. Most commentary treats these as variations of the same attack. They are not. Each has different preconditions, different detection signals, and different structural causes.

Credential theft is the most common. Attackers obtain a maintainer's npm credentials through phishing, AiTM proxy attacks, infostealer malware, or credential stuffing from separate data breaches. The maintainer retains their account in their own mind; the attacker has parallel access they may not notice for hours or weeks.

Ownership transfer is the least discussed. Attackers identify packages where the original maintainer has reduced activity or expressed burnout, offer to help, are granted publishing rights voluntarily, and then weaponise that access. The original maintainer hands over the attack surface willingly. The event-stream case in 2018 is the canonical example.

Offboarding failure is the most preventable. A former contributor or employee retains publishing rights after leaving a project or organisation. No credential theft required. The access was legitimate once and was never revoked. The Ledger Connect Kit attack in December 2023 cost $600,000+ via exactly this mechanism.

All three entry points share one outcome: valid credentials used to publish a malicious version that the registry distributes as a legitimate update.

How npm Maintainer Account Attacks Have Evolved: From Event-Stream to Axios

The incidents below are not related by actor, payload, or target sector.

← Scroll to see full table

Sources: npm Security (event-stream), Unit 42, Wiz, Datadog Security Labs, Google Threat Intelligence Group, Check Point, GitLab, Socket. These are the well-documented public cases. Incidents where compromised versions were removed before wide detection or without public disclosure are not captured here.

The detection time column tells one story. Detection has improved substantially, from 2.5 months for event-stream to three hours for Axios. That improvement is real. What the column does not show is the exposure model: the damage in every case happened at install time, before any advisory existed, before any version was removed. Three hours of exposure for a package present in 80% of cloud environments is still a significant blast radius. Faster detection compresses the window. It does not change what happens inside it: a poisoned package can still execute across millions of environments and do damage before the first advisory is published.

Look at the entry point column and a different pattern emerges. Three distinct mechanisms appear across the documented period. The payload varies by generation. The structural gap that enables all three is the same.

event-stream (2018): The Ownership Transfer That Predicted Everything

The event-stream attack is the case most security teams know least about, and it matters most for understanding where the attack surface is heading.

In September 2018, a GitHub user called right9ctrl approached Dominic Tarr, the original author of event-stream, and offered to help maintain the package. Tarr had not actively worked on it in years. He accepted, granting right9ctrl full npm publishing rights. Shortly after, right9ctrl added flatmap-stream as a dependency. That package contained an encrypted payload targeting the Copay Bitcoin wallet application specifically: a targeted, surgically precise attack delivered through a package Tarr had effectively abandoned.

The malicious code ran undetected for 2.5 months. When it was discovered in November 2018, Tarr could not remove it. He had already transferred his publishing rights and no longer had access (npm Blog, 2018).

There was no credential theft. There was no phishing. The attacker identified a burned-out maintainer, made a credible offer of help, and was handed the attack surface voluntarily.

Right9ctrl had read a three-year-old GitHub comment where Tarr had expressed openness to flatmap functionality. They published a clean version of flatmap-stream first to establish a minimal registry history, then added the malicious version later. The preparation was methodical and patient. The social engineering required a single message.

This is the attack class that is most directly tied to open source sustainability. Tidelift's 2024 survey of over 400 open source maintainers found 60% had quit or considered quitting, with burnout, competing life demands, and loss of interest the leading reasons. The event-stream attack did not exploit a technical vulnerability. It exploited the gap between a package's download count and its maintainer's capacity to care for it.

Shai-Hulud Wave One: Where Self-Replicating Worms Began

The September 2025 attack was the first documented self-replicating worm in the npm ecosystem. The entry mechanic was credential theft via phishing. Familiar. What was new was the automation layer: once the worm obtained a maintainer's npm token, it published malicious versions of every other package that token controlled, then used credentials stolen from new victims to keep spreading. No human intervention required after initial access.

Over 500 packages were compromised in that first wave, including chalk (299 million weekly downloads) and debug (47 million weekly downloads). Roughly 10% of cloud environments pulled compromised packages within two hours.

For the full technical breakdown of Wave One and the initial CISA advisory response, see the npm supply chain poisoned packages analysis. The November wave built directly on what Wave One established.

Shai-Hulud Wave Two: What the Second Coming Added

The November 2025 wave demonstrated that the actors retained their tooling and were actively developing it. Three technical changes from Wave One to Wave Two show the direction of travel.

Execution timing. Wave One used post-install scripts. Wave Two shifted to pre-install execution. Even a cancelled or failed installation can trigger the payload. The attack surface expanded without any change to the social engineering or credential theft layer.

Runtime evasion. Wave Two used the Bun runtime to execute the malicious payload rather than Node.js. Check Point assessed this as deliberate: Bun execution bypasses security tooling that monitors Node.js process behaviour specifically. The first generation evaded detection through speed. The second generation added targeted evasion of the specific defences the first generation had prompted teams to deploy.

Dead man's switch. If the malware could not establish an exfiltration channel or steal further credentials, it defaulted to deleting every writable file in the user's home directory. GitLab's security team identified this mechanism. It created a containment problem: aggressive takedown of compromised accounts risked triggering destructive payloads on machines already infected.

Wave Two affected 796+ packages across roughly 350 GitHub accounts. A third variant appeared in December 2025, confirming the actors retained source access months after the initial campaign.

Is Shai-Hulud Still Active?

Three documented waves appeared between September and December 2025. No confirmed Wave Four activity has been publicly reported following npm's revocation of all classic tokens on December 9, 2025, the first structural registry change to come directly out of the campaign.

Quiet is not the same as resolved. The self-replicating worm technique remains viable against any maintainer account not protected by phishing-resistant MFA and OIDC trusted publishing. A new campaign using updated evasion and a different phishing kit would look different enough from the original variants to bypass signature-based detection.

The worm itself may be dormant. The technique is not.

The Axios Attack: Precision Targeting by a State Actor

The March 2026 Axios compromise is documented in full in the Axios npm supply chain attack breakdown, including IOCs, persistence artefacts, and attribution. The pattern-level points are these.

What made this case different from every previous instance was the preparation timeline. It did not start when the malicious versions appeared on March 31, 2026. It started two weeks earlier, when the attacker built a fake company with a cloned founder identity, a live Slack workspace populated with plausible team profiles and LinkedIn activity, and accounts impersonating other open source maintainers, all designed to feel like a credible professional environment over time, not at a single moment.

Axios maintainer Jason Saayman was invited into that environment, told something needed installing during a Microsoft Teams call, and installed it. That was the RAT. The entire credential theft happened before a single line of malicious code touched the registry.

Three hours of exposure, a package present in 80% of cloud environments, and one social engineering operation that took two weeks to stage. That is the economics of targeting a trusted open source maintainer.

Google Threat Intelligence Group attributed the attack to UNC1069, a North Korea-nexus financially motivated threat actor. Saayman's post mortem, one of the most detailed incident disclosures I have seen from an open source maintainer, acknowledged that the OIDC publishing workflow that would have flagged the compromise was not in place. The signal was in the registry metadata before any damage occurred. Nobody was watching for it.

How North Korean Actors Use npm Maintainer Compromise for Financial Gain

The Axios attack followed a documented progression by the same actor cluster.

In December 2024, two malicious versions of @solana/web3.js appeared via a compromised maintainer account. The package had approximately 400,000 weekly downloads and was used directly in cryptocurrency wallet applications. The malicious versions stole private keys. Infrastructure analysis linked the operation to North Korean state actors. Versions were live for approximately five hours.

Three months later: Axios. Same cluster (UNC1069 per Google, Sapphire Sleet per Microsoft), same technique, larger target. The Solana attack targeted a package used by cryptocurrency developers. The Axios attack targeted a package present in 80% of all cloud environments. The scope expanded. The technique did not.

Sonatype's 2026 report documented over 800 Lazarus Group-associated packages on npm in 2025 alone, with 97% concentrated on the JavaScript ecosystem. This is a sustained, state-funded campaign treating npm as a revenue-generation channel, not a series of opportunistic incidents.

The Ledger Connect Kit attack in December 2023 fits the same financial motivation profile without confirmed attribution to the same cluster. Financially adjacent packages, short exposure windows, direct cryptocurrency theft. Whether or not the same actor is responsible, the targeting logic is identical.

The financial motivation is consistent. So is the response time. Both point to the same gap: security programmes built around traditional perimeters are not watching the npm publish layer at all.

Why Faster Detection Does Not Solve the npm Supply Chain Problem

Shai-Hulud Wave One took weeks to surface. The Axios attack was flagged by StepSecurity within three hours of the malicious versions appearing.

That improvement is real. It does not change the fundamental exposure model.

The damage in these attacks happens at install time, before any advisory exists, before any version is removed, before any detection rule fires. Faster detection compresses the window. It does not change what happens during it. The three-hour Axios window still reached a meaningful percentage of the 80% of cloud environments running the package. Specifically those that ran npm install between 00:21 and 03:15 UTC without a lockfile pinning them to a specific version.

Addressing that window directly requires not pulling the malicious version in the first place. Lockfiles and version pinning ensure npm install resolves to what you decided rather than to whatever latest currently points to. Provenance checking catches the signal before install. Behavioural monitoring at install time catches what CVE-based scanners cannot see.

In my experience, lockfile discipline is the most consistently skipped control in this category. The usual objection is upgrade friction: pinning versions means security patches and bug fixes do not arrive automatically, you have to deliberately update. That is true. But silent automatic upgrades are precisely the attack surface. The Axios compromise reached environments that pulled 1.14.1 with no human decision involved. Tools like Dependabot and Renovate eliminate most of the friction argument anyway; they automate the version bump pull request and surface it for review. You get deterministic installs and a human checkpoint before anything changes.

The detection-exposure paradox is the reason improving detection response time is necessary but not sufficient. The blast radius is determined by install frequency during the window, not by window length alone.

The OIDC Gap That Has Been Available Since 2022

Every legitimate axios release prior to the attack was published via GitHub Actions using OIDC trusted publishing, a mechanism that ties each release to a verifiable workflow run, a specific commit, and a repository tag. axios@1.14.1 had none of that. No trusted publisher block, no gitHead, no matching repository tag.

That signal was in the npm registry metadata before anyone ran npm install. A package with an established automated release process that suddenly ships a version with no provenance metadata is an anomaly. It was there before any damage occurred. Most teams have no process to look for it.

OIDC trusted publishing has been available on npm since 2022. Saayman acknowledged in his post mortem that it should have been in place. The axios repository now uses it. The thousands of other high-download packages that do not are carrying the same exposure, with the same detectable signal sitting unchecked in their registry metadata.

Socket and StepSecurity check provenance automatically. For teams without those tools, verifying the _npmUser and trustedPublisher fields for a new version of a critical dependency before installing takes thirty seconds.

How AI and Attacker Patience Are Accelerating npm Maintainer Attacks

Each generation of this attack class has inherited from the previous one and added one new capability. Opportunistic credential stuffing gave way to phishing campaigns. Phishing gave way to automated worm propagation. Propagation gave way to precision state-sponsored social engineering. The next development is already visible in the data.

The ownership transfer attack surface is expanding, not shrinking. The event-stream case exploited package abandonment. Open source maintainer burnout is structural: 60% of maintainers have quit or considered quitting (Tidelift, 2024), with burnout, competing life demands, and loss of interest as the primary drivers. AI coding tools are accelerating package creation without solving the maintenance sustainability problem. More packages are created each year, the number of maintainers per package skews heavily toward one, and the packages most likely to be abandoned eventually are the ones built quickly during periods of high AI-assisted productivity. The ratio of maintained to abandoned packages is not improving. The attack surface the event-stream compromise exploited in 2018 is growing.

AI compresses the preparation timeline. The Axios operation required two weeks of manual effort to build a convincing fake company, populate a Slack workspace, and establish a credible maintainer identity. AI-assisted persona construction compresses that. Consistent commit histories, realistic communication patterns, credible open source contributor profiles: the preparation cost for a targeted social engineering operation is falling. The most extreme documented case of maintainer patience sits outside npm: the xz utils backdoor (2024), where an attacker spent approximately two years as a contributor before inserting a backdoor into a core Linux compression library. AI does not eliminate the need for patience. It makes patience cheaper.

CI/CD is the next propagation layer. Shai-Hulud used stolen npm tokens to spread across packages. The logical escalation is using CI/CD secrets present in compromised developer environments (GitHub Actions tokens, AWS keys, service account credentials injected into pipelines) to move beyond the registry entirely, into cloud infrastructure and deployment pipelines. The npm compromise becomes initial access. Several packages in the Shai-Hulud campaign already had GitHub Actions workflows; the worm created new workflow files as a persistence mechanism. Replacing that with quiet credential exfiltration is a smaller step than it appears.

The AI hallucination registration window is a separate and growing attack class. Sonatype's 2026 report confirmed that 28% of LLM-assisted dependency upgrade recommendations reference package versions that do not exist. Attackers can register those hallucinated names proactively and wait. No credential theft. No social engineering. Invisible to every CVE-based scanner because the package is malicious by design from registration. This is distinct from maintainer compromise but it is growing alongside the traditional techniques rather than replacing them.

The target profile for the next significant maintainer account attack is predictable from the cases documented above: a single-maintainer package with high weekly downloads, no OIDC trusted publishing enforced, used in cloud infrastructure or financially adjacent workflows, maintained by someone with a visible professional presence that can be researched and impersonated, or someone showing signs of burnout who might welcome an offer of help.

That description applies to hundreds of packages on npm right now.

How the broader supply chain risk picture is evolving beyond the registry layer, into third-party software governance, build infrastructure, and the organisational controls that analyst predictions have both captured and missed, is a separate question. The Gartner supply chain retrospective covers where the analyst consensus stood after 2025. The gap between that consensus and what the incident data now shows is where the next piece in this series starts.

How to Reduce npm Maintainer Compromise Exposure

The controls that work against this attack pattern address the credential layer and the window, not the payload.

Pin versions and commit lockfiles. package-lock.json and yarn.lock ensure npm install resolves to what you decided, not to whatever latest currently returns. Use npm ci in CI/CD pipelines: it fails loudly if the lockfile is out of sync rather than silently resolving to a newer version. This is the single control that directly addresses the exposure window every case in this article exploited. It will not prevent a compromise. It will determine whether your environment pulls a malicious version during the three-hour window.

Phishing-resistant MFA is what TOTP cannot provide against the credential theft entry point. TOTP codes are bypassed by AiTM phishing, the technique used in the Shai-Hulud campaign and almost certainly in the Solana attack. FIDO2 hardware keys and passkeys are not bypassable by the same method. If npm and GitHub accounts across your development team are protected by TOTP only, the credential theft vector that runs through the majority of documented cases remains fully viable. The infostealers guide covers how session tokens and credentials are harvested at scale.

Audit publishing rights and revoke access on offboarding. The Ledger case required no sophisticated attack. A former employee's npm account retained publishing rights after they left. Quarterly audits of who holds npm publish rights for packages your organisation maintains or depends on, combined with prompt revocation on departure, eliminate the offboarding failure entry point entirely. This is the most preventable of the three.

Check provenance before installing critical packages. For packages with established automated release processes, verify new versions carry a matching OIDC trusted publisher block via the npm registry API. A package that historically ships via GitHub Actions CI publishing a version with no provenance metadata is the signal, and it is available before install, not after. Socket and StepSecurity surface this automatically. Without those tools, checking the _npmUser and trustedPublisher fields takes thirty seconds per package.

npm audit will not catch a freshly poisoned version of a trusted package during the exposure window. The Axios payload was already self-destructing by the time any advisory appeared. Tools like Socket and Aikido Security work behaviourally, flagging install scripts in previously script-free packages, obfuscated code blocks, and unexpected network destinations, without waiting for a CVE assignment. Layering one alongside npm audit closes a detection gap the standard tooling cannot see.

For the complete npm security tooling comparison and dependency audit methodology, the npm security vulnerabilities hub covers it in full. For the hands-on auditing approach, the npm supply chain auditing guide and the custom npm vulnerability scanner are the practical starting points.

Closing

The attack that compromised event-stream in 2018 exploited a burned-out maintainer handing over a package they no longer had capacity to care for. The attack that compromised axios in 2026 exploited a maintainer who had no reason to distrust a professional contact in a credible-looking Slack workspace.

Different entry points. Different actors. Different preparation times. The same structural gap: the registry cannot distinguish the authorised maintainer from whoever currently holds the credentials.

That gap is not narrowing. The open source ecosystem is creating more packages, sustaining fewer of them, and building more production infrastructure on top of both. The attack surface the first case exploited in 2018 is structurally expanding. The precision of the attacks is increasing. And the preparation cost is falling.

The next incident will look different. The entry point will be the same: a registry that trusted whoever held the credentials.

Key Resources:

• Poisoned Packages: Auditing the npm Supply Chain - Shai-Hulud Wave One, September 2025
• Axios npm Supply Chain Attack (2026) - Full incident breakdown, IOCs, and attribution
• npm Security Risks: Most Vulnerable Packages in 2026 - Complete npm security hub
• npm Vulnerability Scanner - Custom scanner using the deps.dev API
• Gartner Supply Chain Retrospective - Broader supply chain context

References:

• npm Security Blog (2018). Details about the event-stream incident. npmjs.org.
• Snyk (2018). A post-mortem of the malicious event-stream backdoor. snyk.io.
• Tidelift (2024). The 2024 Tidelift State of the Open Source Maintainer Report. 60% quit or considered quitting; burnout, competing life demands, and loss of interest as primary drivers.
• Unit 42, Palo Alto Networks (2025). Shai-Hulud worm analysis, waves 1 and 2.
• Wiz Research (2025). Shai-Hulud 2.0 supply chain attack.
• GitLab (2025). Dead man's switch mechanism, wave 2 analysis.
• Check Point (2025). Shai-Hulud 2.0: Bun runtime evasion analysis.
• Datadog Security Labs (2025). Shai-Hulud worm analysis.
• Google Threat Intelligence Group (2026). UNC1069 attribution, Axios npm supply chain attack.
• Microsoft Threat Intelligence (2026). Sapphire Sleet attribution, Axios infrastructure.
• Jason Saayman (2026). Axios maintainer post mortem. GitHub axios/axios issue 10636.
• StepSecurity (2026). Detection of Axios malicious versions.
• Sonatype (2026). 11th Annual State of the Software Supply Chain Report.
• Aikido Security (2025-2026). Shai-Hulud variant 3, December 2025.
• CISA (2025). Alert: Widespread Supply Chain Compromise Impacting npm Ecosystem.

Frequently Asked Questions

Is Shai-Hulud still active?

Three waves of Shai-Hulud activity were documented between September and December 2025. No confirmed Wave Four activity has been publicly reported. npm revoked all classic tokens on December 9 2025 in direct response to the campaign. The self-replicating worm technique remains viable against maintainer accounts not protected by phishing-resistant MFA and OIDC trusted publishing. A new campaign using updated evasion would bypass signature-based detection of the original variants.

What npm packages were affected by Shai-Hulud?

The September 2025 wave compromised 500+ packages including chalk (299 million weekly downloads) and debug (47 million weekly downloads). The November 2025 second wave expanded to 796+ packages affecting projects from Zapier, ENS Domains, PostHog, and Postman. A third variant appeared in December 2025.

How do npm maintainer account attacks work?

npm maintainer account attacks have three documented entry points. Credential theft: attackers obtain a maintainer's npm credentials through phishing, infostealer malware, or credential stuffing. Ownership transfer: attackers identify abandoned or poorly maintained packages and offer to help, gaining publishing rights voluntarily. Offboarding failure: a former contributor retains publishing rights after leaving a project. In all three cases, the attacker uses valid credentials to publish a malicious version that the registry distributes as a legitimate update.

What is the difference between Shai-Hulud and the Axios npm attack?

Shai-Hulud (2025) was a self-replicating worm that spread autonomously across hundreds of packages after phishing maintainer credentials at scale. The Axios attack (March 2026) was a precision operation by North Korean state actor UNC1069, targeting a single high-value maintainer through two weeks of social engineering before publishing two malicious versions of a package with 100 million weekly downloads. Both used the same core entry point: compromised maintainer credentials to publish malicious package versions.

What was the event-stream npm attack?

In November 2018, a malicious actor called right9ctrl was discovered to have inserted a targeted payload into event-stream, a package with approximately 2 million weekly downloads. The attack used ownership transfer rather than credential theft: right9ctrl offered to help maintain the package, the original author Dominic Tarr accepted and transferred full publishing rights, and the malicious dependency flatmap-stream was added shortly after. The payload targeted the Copay Bitcoin wallet and ran undetected for 2.5 months.