Attackers Can Hijack npm Packages Without Stealing Developer Credentials

A flaw in npm’s Trusted Publishing mechanism could let attackers publish malicious updates to legitimate packages without compromising a developer’s npm account, GitHub account, or publishing token.

Researchers identified more than 1,500 potentially exposed packages with over 10 million combined downloads.

The weakness is particularly concerning as AI coding agents increasingly select, install, and execute npm dependencies autonomously.

A malicious package release no longer needs to persuade a developer to manually run an installation command; it only needs to be selected by an agent during a coding, build, or CI task.

npm Trusted Publishing was designed to remove long-lived registry tokens from CI/CD pipelines.

Instead, a GitHub Actions workflow obtains a short-lived OpenID Connect (OIDC) token and exchanges it for a time-limited npm publishing credential.

The model reduces exposure to leaked secrets in build logs, repositories, and automation systems.

However, the trust relationship initially relied on a GitHub repository slug: the human-readable owner/repository path. A slug is not permanent.

It can become available after a repository is renamed, transferred, or deleted, or when its owner changes names or disappears.

GitHub’s OIDC tokens include immutable identifiers, such as repository_id and repository_owner_id, which persist across renames and transfers. But npm did not initially bind Trusted Publishing to those identifiers.

Instead, the binding could remain associated with the reclaimable slug until the first successful trusted publish.

That opened a package takeover path. An attacker could claim the abandoned GitHub path, create a workflow with the expected filename, obtain a GitHub Actions OIDC token, and exchange it for a valid npm publish credential.

The attacker would not need access to the original maintainer’s credentials or repository.

Bloom Security demonstrated the attack in a controlled environment using repositories and an npm scope it owned.

The researchers found that a newly created repository under a reclaimed slug could publish to a package that still trusted the former location.

A successful attacker could publish a new version under the victim package’s legitimate name, inheriting its download reputation and its existing place in the dependency graph.

The malicious release could include a postinstall lifecycle script, allowing code to run when developers, CI systems, or automated tools execute npm install.

The impact extends beyond direct users. A single hijacked package can affect downstream projects through transitive dependencies, turning a repository-identity validation failure into a broad software supply-chain event.

The issue, dubbed SlugFest by Bloom Security, stemmed from npm initially trusting a mutable GitHub repository name rather than its immutable repository identity.

npm Packages hijacked

Researchers cautioned that provenance alone may not prevent the attack: a Sigstore attestation could still appear valid if tooling verifies only that a package is signed, rather than verifying that its provenance points to the expected maintainer-controlled repository.

The research highlights a shift in software supply-chain exposure. Coding agents including Claude Code, Codex, Gemini, and Cursor can independently choose dependencies, install them, and execute package lifecycle scripts with limited human review.

Across dozens of organizations, Bloom measured about 70 direct agent-installed packages per endpoint each month, rising to roughly 350 per month on developer machines.

Those figures exclude transitive dependencies, meaning the real dependency footprint can be substantially larger.

This does not mean AI agents caused the vulnerability. Rather, they can amplify its consequences.

A compromised release can be pulled into environments at machine speed, potentially before a developer notices the dependency selection or reviews the package’s release history.

Bloom reported the issue through GitHub’s HackerOne program on June 6, 2026, and said the report was validated on June 9. GitHub deployed a mitigation on October 2, more than 120 days later.

npm now expires unvalidated Trusted Publishing configurations 48 hours after they are created.

A configuration becomes validated after its first successful publish; if it is not used within the two-day window, it can no longer authorize a release.

GitHub said the change reduces the risk that a repository or project name changes ownership before the publisher identity is validated.

npm also rejects Trusted Publishing tokens triggered through GitHub Actions issue_comment events, supplementing an existing restriction on pull_request_target.

Maintainers using affected workflows should move publishing to permitted events such as push, release, or workflow_dispatch.

Maintainers should review each Trusted Publishing configuration and verify that its linked GitHub repository remains under their control.

Existing bindings should be deleted and recreated after a repository rename, transfer, or ownership change.

Before deleting a repository tied to an npm package, maintainers should remove or replace its Trusted Publisher configuration first. Running npm trust list can help identify configured publishing relationships.

For enterprise defenders, the incident reinforces a broader requirement: AI agents must be treated as autonomous software consumers.

Controls should govern which packages agents may install, inspect lifecycle scripts such as postinstall, pin or review dependency updates, and continuously monitor unexpected package releases in high-value dependency chains.

Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.