npm Hijacking Wave: coa, rc, node-ipc and Stolen Maintainers

Early November 2021 poisoned the well every JavaScript developer drinks from: a wave of npm account compromises hit popular packages — coa, rc, node-ipc (via maintainer-account takeover), and others — replacing legitimate releases with install-scripts that executed malicious postinstall payloads on developer machines and CI pipelines worldwide. The node-ipc variant delivered an info-stealer (grabbing browser cookies, saved passwords, crypto wallets); the coa/rc Okta-referencing strings baited enterprise SOC escalation searches. The attack class wasn’t new (event-stream 2018, ua-parser-js the month prior), but November 2021 made its mechanics undeniable: package registries run on maintainer accounts, maintainer accounts run on reused passwords and unrotated tokens, and the entire software economy inherits whatever hygiene the most-neglected dependency maintainer practices. The ecosystem’s response trajectory — mandatory 2FA pushes, provenance signing (npm provenance/Sigstore), install-script restrictions — traces directly to this cluster.

What happened

The wave: on 1–2 November 2021, malicious versions of coa (2.0.3+) and rc (1.2.9, 1.3.9) hit the registry — packages sitting invisibly inside billions of transitive install graphs. The postinstall scripts profiled the victim machine and exfiltrated browser credentials, cookies, and desktop-wallet data to hardcoded endpoints; embedded strings naming Okta/Cloudflare-era services made every enterprise SOC’s log search light up, with some organisations executing full incident responses before understanding the actual payload scope. Within days, node-ipc (a utility downloaded millions of times weekly) suffered a maintainer compromise publishing info-stealer versions harvesting browsers, Discord, and cryptocurrency wallets. npm/GitHub responded with takedowns, forced resets for affected accounts, and public post-incident analysis attributing the takeovers to credential compromise — the registry itself was never breached.

The uncomfortable maths underneath: coa had ~9M weekly downloads; rc similar; both had maintainers who hadn’t touched the code in years. Deep in transitive graphs (via React Create App tooling and peers), most victims never knew the packages were installed on their machines — the malicious code ran from inside dependency trees nobody audits manually. The event landed weeks after ua-parser-js (October 2021) and months before the 2022 crypto-stealer waves institutionalised npm as a primary delivery vehicle.

How it worked

The account-to-execution chain:

(1) select target: high-transitive-reach package,
    dormant maintainer (less likely to notice
    publish) - coa, rc, node-ipc class
(2) takeover: credential stuffing / reused
    password / leaked token - registry not
    compromised, the ACCOUNT was
(3) publish: malicious new semver-compatible version
    (patch/minor bump - auto-update friendly)
(4) trigger: postinstall lifecycle script runs
    at install time on developer machines + CI
(5) payload: profile host -> steal browser creds/
    cookies, Discord tokens, wallets, env vars
    -> exfil to hardcoded endpoints
    (CI env vars = deploy secrets = pivot
    credential)
(6) blast radius: transitive graphs put package
    inside thousands of apps;weekly  millions of
    automated installs pull malicious version
(7) detection lag: hours-days (SOC alerts via
    suspicious strings/egress; registry takedown)

The structural insight: install-time code execution is full code execution — lifecycle scripts blur the line between package manager and arbitrary-script runner, which is why script-restriction and provenance-verification became the two central pillars of the post-2021 package-registry defence model, the architecture our supply-chain hardening coverage details.

Impact and numbers

Timeline

Why it still matters in 2026

Because every layer of the modern response architecture was built in this event’s shadow. Mandatory 2FA for high-impact npm accounts (GitHub’s 2022-2023 rollout) closes the specific vector. Provenance signing (npm provenance attesting builds from public repos, Sigstore integration) makes silent substituted publishes cryptographically detectable — the market answer to “you can’t trust the maintainer account” is “you can verify the build lineage”. Lifecycle-script restrictions and sandboxed installs acknowledge the postinstall-execution problem directly. And SBOM-driven consumption policies (allowlist, version-pinning, update-review windows) treat dependencies as the attack surface they proved to be. Meanwhile the adversary side industrialised: cryptostealer crews made malicious npm publishes a routine revenue line through 2022–2025, and the 2024 XZ-utils backdoor (different registry, same maintainer-trust failure mode) demonstrated the strategic-actor version. The 2021 wave remains the cleanest teaching case because every observability gap it exploited — invisible transitive reach, dormant maintainers, install-time execution, reused credentials — now maps to a named, deployable control.

Detection and hardening takeaways

• Disable dependency lifecycle scripts by default. ignore-scripts-class configurations (or sandboxed install environments) remove the entire postinstall-execution class; allowlist the few packages with legitimate build needs.
• Verify provenance and pin versions through controlled updates. Lockfiles plus automated update PRs create a human-review window; provenance/signature checks confirm the artifact matches public source — silent substituted publishes fail both gates.
• Proxy and allowlist your registry consumption. Private registries (Artifactory/Nexus class) with namespace policies, new-maintainer and new-version release vetting, and egress control prevent developer machines from pulling tomorrow’s malicious release at install time.
• Keep secrets out of install-time reach. CI environments that hand deploy credentials to every build step give postinstall scripts their most valuable payload — scoped, short-lived tokens and secret-isolation limit exfiltration yield to noise.
• Monitor dependency-graph alerts as a first-class SOC feed. Registry advisories and lockfile diffs (new versions, new packages, script additions) belong in alerting pipelines — the coa/rc horde was caught by string-matching egress, but graph-diff alerting catches it pre-execution.

FAQ

Was npm itself hacked?

No — and the distinction matters. The registry infrastructure stayed intact; individual maintainer accounts were compromised through credential stuffing, password reuse, and token leakage. That’s why the fix was account-security reform (2FA mandates, scoped tokens) rather than registry rebuild — and why “the registry wasn’t breached” offered cold comfort to the millions whose install scripts ran attacker code anyway.

Why did packages nobody updates get compromised so easily?

Dormancy was the feature, not the bug. Packages with years-stale maintainership carry reused passwords, unrotated tokens, and no one watching the publish log — perfect takeover targets with maximal transitive reach. The ecosystem’s answer combines mandatory 2FA on impactful accounts with gradual mechanisms for stewardship transfer, an ongoing governance problem the 2024-era registries still wrestle with.

If my project had these packages, what actually ran on my machine?

For coa/rc: a postinstall that profiled your system and exfiltrated browser-saved credentials, cookies, and environment details. For node-ipc: an info-stealer targeting browsers, Discord tokens, and crypto wallets. On CI: whatever environment variables your pipeline exposed — potentially deploy credentials. The response: rotate everything the install context could read, scan for persistence, and treat affected build agents as compromised until rebuilt.