npm account takeover, abbreviated ATO, used to be a story about reused passwords and tired maintainers. In 2026 it is a story about coordinated multi-stage operations, supply chain reconnaissance, and credential infrastructure that resembles the early days of organized e-crime more than the lone-attacker stereotype that lingered through the late 2010s.
This post traces the evolution of npm ATO tradecraft from 2025 into the first quarter of 2026, drawing on registry telemetry, public incident write-ups, and patterns visible in the package metadata of compromised modules.
The 2025 baseline
For most of 2025, npm ATO followed a recognizable pattern. An attacker would obtain credentials for a maintainer, usually through credential stuffing against npmjs.com using leaked password databases. They would publish a single new version of a popular package containing a small post-install script. The script would exfiltrate environment variables and SSH keys to a hardcoded webhook, and the campaign would be discovered within hours by automated detection systems run by registry security teams and third-party scanners.
The economics were marginal. A successful campaign reached a few thousand downloads before the malicious version was pulled. Detection-to-removal times averaged under four hours by mid-2025, and the financial yield per ATO was low enough that most operations appeared to be experimentation rather than production. The threat actor pool was wide and shallow.
Two things changed that calculus across the second half of 2025.
What shifted in late 2025
The first shift was the increased use of session token theft over password compromise. Maintainers were enrolled in 2FA at much higher rates by late 2025, partly because of registry-mandated enrollment for high-impact packages. Password-only ATO became sharply less effective. In response, attackers pivoted to stealing local npm CLI tokens directly from developer workstations, typically through info-stealer malware delivered via fake job offers, malicious VS Code extensions, or compromised dependencies in unrelated personal projects.
The second shift was reconnaissance before publishing. Older campaigns published immediately upon getting access. Newer campaigns sit on access for days or weeks, study the maintainer's normal release cadence, and time their malicious publication to coincide with an expected legitimate release window. This dramatically delays detection because the new version does not look anomalous in either timing or commit volume.
By December 2025, registry teams were reporting that the median time-to-detection for sophisticated ATO publications had grown from four hours to roughly thirty hours. The fast-and-loud campaigns continued, but the slow-and-quiet ones started accumulating real victim counts.
The 2026 pattern
The first quarter of 2026 has crystallized a multi-stage operating model.
Stage one is credential acquisition through an info-stealer ecosystem that is now largely shared with mainstream e-crime. The same malware families harvesting browser cookies and crypto wallet seed phrases also harvest npm tokens, GitHub PATs, and SSH keys. There are at least three log markets where these credentials are sorted, indexed, and sold by ecosystem.
Stage two is target selection. Buyers query the markets specifically for npm tokens belonging to maintainers of packages above a download threshold, often expressed as weekly downloads or transitive dependency reach. The market interfaces support exactly this kind of search.
Stage three is reconnaissance and patience. Operators study the maintainer's GitHub activity, the package's release notes, and any open issues or pull requests that suggest an upcoming legitimate release. They map the package's dependents to identify high-value downstream targets.
Stage four is the malicious publish, often disguised as a routine maintenance release. The malicious code is increasingly deployed as a second-stage loader rather than an inline payload, with the loader pulling its real instructions from a typo-squatted domain or a public paste service. This makes the published package itself look mostly clean to surface-level scanners.
Stage five is selective targeting. Rather than exfiltrating everything, modern loaders check environment variables, hostnames, and process trees for indicators of the intended downstream victim. If the package lands somewhere uninteresting, the loader does nothing. If it lands inside a target's CI runner, it triggers.
The data behind the pattern
Registry-side telemetry for the first three months of 2026 shows roughly 130 confirmed ATO publications across npm, compared to about 95 in the same window of 2025. Median time-to-detection has held at around twenty-eight hours, suggesting that detection improvements and attacker stealth are roughly canceling out.
Among the 2026 incidents, roughly forty percent involved second-stage loader patterns rather than inline payloads. About twenty-five percent showed clear evidence of pre-publish reconnaissance based on the timing relative to the maintainer's prior release cadence. Roughly fifteen percent contained victim-selection logic in the loader.
The economic yield per successful ATO appears to have grown materially. Public incident reports from late 2025 and early 2026 describe several ATO-driven breaches resulting in seven-figure ransom demands or direct cryptocurrency theft, where the npm package was the entry point but the actual monetization happened against a downstream user.
Maintainer-side defenses for 2026
The maintainer threat model has changed enough that older guidance no longer suffices. Specifically, three new practices have moved from optional to expected.
Hardware-backed authentication for publish operations is the new floor. Tokens stored on disk, even in encrypted form, are within reach of info-stealers. WebAuthn-bound publish flows or hardware-token-protected granular access tokens close that door.
Publish-time verification is becoming common. Trusted publishing flows that bind a release to a specific GitHub Actions workflow, with provenance attestations recorded at publish time, allow consumers to verify that a package version came from the expected build pipeline rather than from an arbitrary developer machine.
Release process formalization helps too. Maintainers who publish on a predictable cadence from a documented branch, with signed tags and visible CI runs, make anomalies easier for both registry security and downstream consumers to spot.
Consumer-side defenses
For organizations consuming npm packages, the defensive posture should assume that any given dependency may be silently compromised for a window of roughly twenty-four to seventy-two hours per year per high-impact package. That assumption drives several practices.
Dependency pinning by hash, not just by version, prevents silent retroactive substitution. A pinned hash means the same bytes every install, regardless of what the registry serves.
Cooldown periods on new versions reduce exposure to fast-moving campaigns. Internal mirrors that delay propagation of new versions by twenty-four to seventy-two hours have repeatedly caught ATO publications before they reached production builds.
Provenance verification at install time, where supported, raises the cost of forging legitimate-looking releases. Consumers who insist on provenance attestations push the ecosystem toward a model where ATO without also compromising a build pipeline becomes meaningfully harder.
Registry-side response
Registry operators have not been passive. The visible 2026 response includes mandatory hardware-backed authentication for maintainers of high-impact packages, expanded behavioral analysis of publication events, and stricter rate limiting on operations that historically correlate with takeover activity. The combined effect is meaningful enough to be visible in the data: the share of ATO publications that come from credential stuffing alone has dropped sharply, while the share involving session token theft and persistent operator infrastructure has grown.
The remaining gap involves the long tail of packages below the high-impact threshold. Maintainer hardening has been concentrated where the impact is greatest, which is rational from a registry perspective but leaves a substantial number of less-popular packages with weaker defenses. Attackers have noticed, and a non-trivial share of 2026 incidents involves chains where a less-protected upstream package is compromised first, then used as a stepping stone to reach a more-protected downstream consumer through transitive dependency relationships.
The ecosystem-level direction is clear but the implementation is uneven. By the end of 2026, defenders should expect that maintainer hardening below the headline-package tier will continue to lag, and the attack surface will continue to concentrate there.
How Safeguard helps
Safeguard's package security analysis correlates registry signals across npm and other ecosystems, flagging publications that deviate from a maintainer's historical pattern, that lack expected provenance attestations, or that contain second-stage loader indicators visible in static analysis. When a package version appears in a customer's dependency graph and later turns out to be compromised, Safeguard's transitive dependency mapping surfaces every project, build artifact, and deployed product affected, and the AI remediation engine generates pinned-version replacement plans tailored to each affected manifest. Combined with policy gates that enforce cooldown periods and provenance requirements, this gives security teams a structural defense against the ATO patterns dominating 2026, rather than a reactive scramble after the next compromised package lands in a build.