Post Mortem: axios NPM supply chain compromise

Original Article ↗ Hacker News Discussion ↗

Attack vector and detection

  • Compromise came via social engineering: fake Zoom/Teams-style meetings that prompted the maintainer to run “troubleshooting” commands, leading to a RAT installed on the dev machine.
  • The RAT could run arbitrary shell commands; once an owner machine was pwned, publishing malicious packages was straightforward.
  • Malicious Axios versions were detected within about an hour; initial bug reports were deleted by the attacker using the compromised account, but the window of exposure was still only a few hours.

NPM, OIDC, and registry limitations

  • Axios v1 used OIDC “trusted publishing” with provenance attestations; the malicious publish lacked those attestations but the registry still accepted it.
  • Commenters note there is (or should be) an option to require OIDC-only publishing, but the UX is confusing and many maintainers don’t enable it.
  • OIDC and registry policies can’t fully help once local npm publish from a compromised machine is allowed.

2FA, hardware tokens, and RAT limits

  • TOTP codes stored or generated on the same compromised machine are useless; RATs can steal seeds or intercept codes.
  • Some argue hardware tokens or air‑gapped authenticator devices reduce risk; others point out RATs can wait for legitimate hardware-token use and piggyback on existing sessions.
  • Consensus: 2FA helps against account takeover, but not against a patient attacker with full control of the maintainer’s box.

Code signing, attestations, and provenance

  • One camp insists multi-party commit/review/release signing with hardware keys, deterministic builds, and strict verification would have prevented or limited the impact.
  • Critics respond that NPM doesn’t enforce any of this, attacks bypassed Git entirely, and manual key management at NPM’s scale is fragile and unrealistic.
  • There’s repeated frustration that NPM rejected optional package signing years ago and treats verification as optional “decor.”
  • Several note the strongest unused signal here: legitimate releases had provenance attestations; the malicious one didn’t, but almost nobody checks attestations in CI.

Responsibility and ecosystem incentives

  • Some argue maintainers have an ethical obligation (even as volunteers) to apply basic supply-chain hygiene, like signing code, analogous to doctors washing hands or food banks checking safety.
  • Others counter that OSS licenses explicitly disclaim obligation; users choosing to depend on free software should assume responsibility and can always fork if they need stricter guarantees.

Developer practices and dependency culture

  • Many criticize the culture of “copy this script into your terminal,” viewing it as the root cause enabling social-engineering payloads.
  • There is debate over whether macOS’s weak native package-management story encouraged this culture; others say Linux also sees “copy/paste this command” patterns via AUR/PPAs.
  • Several recommend:
    • Using lockfiles and hashing (already default in modern npm) but also diffing lockfiles on every deploy, especially for new transitive dependencies in patch releases.
    • Avoiding version ranges (^, ~) and instead pinning exact versions plus alerting on lockfile changes.
    • Verifying OIDC/provenance in CI for critical deps.

Minimizing dependencies (Axios vs fetch)

  • Some report replacing Axios with native fetch plus a thin wrapper to reduce the attack surface; fetch is now widely available.
  • Others stress Axios still offers conveniences (interceptors, standardized error handling, JSON parsing, progress events).
  • A view emerges that “reinventing the wheel” with small, project-specific wrappers may now be a rational defensive posture, trading a bit of effort for reduced supply-chain risk.

Proposed registry-level changes

  • Suggestions for NPM include:
    • Allowing high-profile packages to opt into OIDC-only or CI-only publishing, possibly with multi-maintainer approval.
    • Mandating or at least supporting strong signing and passkeys/FIDO2 for both auth and artifact signing.
    • Introducing a brief staging period where new versions are scanned and can be revoked before broad availability, though this clashes with urgent security fixes.
    • Flagging packages with “weak publishing protection” vs multi-signed, strongly protected ones.
    • Banning or tightly controlling postinstall scripts.
  • Skeptics doubt NPM (as part of a large company) will accept any change that adds friction for publishers, even if it improves security.