Malicious Workflow Stole npm Token via Shared Repo; Lockdown Now, OIDC Next

Read Articleadded Sep 17, 2025
Malicious Workflow Stole npm Token via Shared Repo; Lockdown Now, OIDC Next

An attacker force-pushed a malicious GitHub Actions workflow to a shared repo, stealing a broadly scoped npm token and publishing malicious versions of ~20 packages including @ctrl/tinycolor. GitHub/npm quickly removed the compromised versions, and the author released clean builds, revoked tokens, and enforced 2FA and tighter controls. The long-term plan is to adopt npm Trusted Publishing (OIDC) and push for ecosystem improvements like provenance enforcement, protected UI-based publishing, and clearer npm indicators.

Key Points

  • The breach originated from a shared repo’s GitHub Actions secret (a broad npm publish token) exfiltrated by a malicious workflow pushed by an admin collaborator.
  • About 20 malicious package versions were published, including @ctrl/tinycolor; no direct compromise of the author’s account or repo, and no phishing was involved.
  • GitHub/npm rapidly unpublished the malicious releases; the author republished clean versions to flush caches and restore trust.
  • Short-term mitigations: revoke tokens, require 2FA for publishing, restrict contributors, and use granular publish-only tokens; continue pnpm safeguards and consider minimumReleaseAge.
  • Long-term goal: move to npm Trusted Publishing (OIDC) and improve ecosystem support (semantic-release integration, UI-based protected publishing, wider environment protections, and clearer npm visibility for postinstall and removed versions).

Sentiment

The overall sentiment on Hacker News is largely in agreement with the article's assessment of the supply chain vulnerability and the direction of proposed mitigations. There is a strong consensus that static, broad-permission tokens are a major security flaw and that OIDC-based, short-lived tokens, combined with human-in-the-loop MFA for publishing, are critical improvements. While some alternative solutions are proposed (e.g., VCS as source), they are often met with practical counter-arguments, indicating a pragmatic yet security-conscious approach to the problem. The discussion is constructive, analytical, and identifies systemic issues beyond the immediate incident, reflecting a shared concern for supply chain security in open-source ecosystems.

In Agreement

  • The use of long-lived, broad-permission static tokens, especially when stored in shared repositories, represents a critical security vulnerability and should be eliminated.
  • npm Trusted Publishing (OIDC), which provides short-lived, workflow-bound tokens, is a crucial step towards securing automated publishing flows and should be widely adopted.
  • Separating the package upload process (which can be automated) from the final package publishing step (which should require human review and MFA) is a valuable security enhancement.
  • The "two-person rule" or a time-lock delay for publishing, similar to human-in-the-loop MFA for sensitive CI actions, would add significant security layers.
  • The problem of "old sins" or forgotten legacy configurations (like an outdated token in an old repository) is a common and dangerous vector for compromise.
  • Package managers should prioritize downstream user security over author convenience, potentially through stricter publishing controls and approval processes.
  • Even for automated workflows, implementing a 'sudo mode' or MFA prompt for sensitive operations would enhance security.

Opposed

  • The entire concept of 'publishing packages' might be unnecessary; using a Version Control System (VCS) directly as the source of truth (similar to Go modules) could remove an entire attack surface.
  • Using VCS directly as the source of truth for packages has significant downsides, including longer install times, the need for a full local toolchain, and reduced build reproducibility, especially in JavaScript ecosystems.
  • While OIDC flows are generally more secure, they can be complex to configure and may still be vulnerable if the workflow itself is compromised, as the attacker could still execute arbitrary code within the compromised workflow environment.
  • Requiring multiple authors or trusted third-party approval for every package, while secure, could hinder discoverability and collaboration for smaller or new open-source projects.
  • The demand for features like multiple authors, trusted third parties, and extensive review for free open-source packages is a form of 'entitlement' from users who haven't contributed financially.
  • Automated publishing workflows are often not justified for the majority of npm packages; manual `npm publish` with 2FA is sufficient and more secure for many projects, reducing the attack surface of automated systems.
Malicious Workflow Stole npm Token via Shared Repo; Lockdown Now, OIDC Next