Flaw in npm Trusted Publishing Exposed Over 1,500 Packages to Supply Chain Hijacking

Overview

Automated publishing workflows took a significant hit after security researchers at Bloom Security disclosed an npm Trusted Publishing flaw that left more than 1,500 npm packages vulnerable to complete package takeover. The design flaw allowed attackers to push malicious updates to existing npm packages without needing to steal maintainer credentials, compromise developer tokens, or breach underlying user accounts. Instead, attackers could exploit stale OpenID Connect (OIDC) trust configurations linked to abandoned GitHub repository names. GitHub, which operates the npm registry, has confirmed the vulnerability and deployed fixes to prevent unauthorized publishing.

How the npm Trusted Publishing Flaw Works

Trusted Publishing was introduced to modernize registry authentication by replacing long-lived API tokens with short-lived OIDC trust relationships between CI/CD providers—primarily GitHub Actions—and the npm registry. When configured, npm grants publish permissions based on claims contained in the caller’s OIDC token, verifying that the request originates from a pre-configured repository (owner/repository).

The security breakdown occurred when maintainers renamed their GitHub accounts, deleted repositories, or transferred project ownership while leaving the Trusted Publishing configuration active on npm. Because GitHub frees up original account and repository names for public re-registration—a phenomenon known as “repojacking”—an attacker could simply re-register the abandoned GitHub username and repository name.

Once the attacker controlled the matching GitHub repository path, GitHub Actions issued valid OIDC tokens identifying the repository as the trusted source. When sent to npm, the registry validated the token claims against its existing Trusted Publishing settings. Because npm evaluated the repository path string rather than an immutable account ID, the registry accepted the attacker’s build and allowed them to publish arbitrary, potentially malicious package versions directly to the public registry.

Supply Chain Impact and Blast Radius

Software supply chain attacks stemming from registry-level takeovers carry immense blast radius potential. Unlike traditional phishing or credential theft where an attacker targets a single developer’s credentials, repojacking exploits latent architectural trust.

Because npm packages frequently serve as transitive dependencies across thousands of enterprise projects, poisoning a single package update can compromise build pipelines, exfiltrate environment variables, harvest runtime secrets, or deploy backdoors directly into downstream applications. With over 1,500 npm packages confirmed exposed prior to remediation, the vulnerability presented a broad opportunity for supply chain compromise across the JavaScript ecosystem.

Remediation and Ecosystem Fixes

GitHub has resolved the issue by strengthening the verification process between GitHub Actions and npm’s Trusted Publishing mechanisms. The registry now incorporates immutable metadata—such as internal account and repository identification numbers—to ensure OIDC token claims strictly match the original entity that established the trusted relationship, rather than relying solely on mutable repository names.

Organization administrators and package maintainers using npm Trusted Publishing should audit their active registry settings:

• Review all packages configured with OIDC trust policies on npmjs.com and remove stale references to renamed or deleted repositories.
• Verify that GitHub organization and repository rename history does not leave orphaned trust configurations on third-party registries.
• Implement automated dependency monitoring and pin package versions using exact semantic versions or subresource integrity checks in enterprise CI/CD builds.