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 community is largely sympathetic to the author and constructively engaged with the security implications. There is broad consensus that the npm ecosystem's token model is dangerously permissive, but genuine disagreement about whether the fix should be more automation (OIDC, trusted publishing) or less automation (manual publishing with 2FA). The discussion is civil and substantive, with the author actively participating and acknowledging valid criticisms.

In Agreement

• OIDC-based Trusted Publishing eliminates long-lived static tokens and is now available for npm — maintainers should adopt it immediately
• The root cause was an overly broad npm token stored in a shared repository; package-scoped tokens with proper permissions would have limited the blast radius
• npm should require human MFA approval for publishing, especially for packages with large download counts, by separating the upload and publish steps
• Forgotten credentials in old shared repositories are a classic and recurring security vulnerability that organizations need to audit proactively
• The author's quick response and transparent post-mortem were exemplary incident handling

Opposed

• OIDC doesn't fully solve the problem because a compromised workflow can still publish using short-lived tokens generated within the same CI environment
• Automated CI/CD publishing is itself the problem — manual local publishing with 2FA is sufficient for the vast majority of packages and would have prevented this attack entirely
• Requiring multi-author review or third-party approval for all packages is unrealistic entitlement given that most packages have a single author contributing unpaid labor
• The fundamental security problem is irreducible — any authentication system ultimately relies on some secret or identity that can be compromised, so improvements are incremental at best
• VCS-based package distribution (like Go) would remove the entire publish attack surface, but the JS ecosystem's build complexity makes this impractical