npm Trusted Publishing Flaw With 10 Million Downloads Exposes 1,500+ Packages to Malicious Takeover

A security flaw in npm’s Trusted Publishing feature exposed more than 1,500 packages to possible takeover through reclaimed GitHub repository names.

The affected packages accounted for more than 10 million total downloads and over one million downloads per month, creating a serious software supply-chain risk for developers, CI/CD systems, and organizations that rely on npm dependencies.

The issue, named SlugFest, did not require an attacker to steal an npm token, break into a maintainer’s npm account, or access the original GitHub repository.

Instead, a threat actor could claim an abandoned GitHub owner/repository name and use it to receive a valid short-lived npm publishing credential for a package that still trusted that old location.

Analysts at Bloom Security identified the flaw and noted that it was a package takeover path, not an active malware campaign.

However, a successful takeover could allow malicious code, including a harmful postinstall script, to be published under a legitimate package name and delivered to users during normal dependency installation.

This risk is especially important after the recent ChainDrop npm worm showed how compromised releases can spread through developer tools, repositories, and automated build environments.

npm Trusted Publishing Flaw With 10 Million Downloads

Trusted Publishing is intended to make npm releases safer. Rather than storing a long-lived npm token in GitHub Actions or another CI/CD service, a maintainer can connect a package to a repository and workflow through OpenID Connect, or OIDC.

During a release, the workflow obtains a short-lived identity token and exchanges it for an npm publishing credential. This removes the need to place reusable publishing secrets in build pipelines. The problem was in the way npm initially linked a package to its publishing repository.

For an unvalidated configuration, npm stored the human-readable GitHub repository path, known as a slug, such as organization/project, instead of immediately storing GitHub’s permanent numeric repository ID and owner ID.

Repository names can change ownership after a project is renamed, transferred, deleted, or when its owner account changes names.

That means an attacker could create a new GitHub repository using the newly available slug, add a workflow with the expected filename, request an OIDC token, and present that token to npm.

If the configured package had never completed its first trusted publish, npm could accept the repository name as a match and issue a valid publishing credential. The attacker could then release a new version under the legitimate npm package name.

This differs from the token theft used in many earlier npm compromises. As explained in Cyber Security News coverage of GitHub’s npm security improvements, Trusted Publishing was designed to reduce exposure from long-lived automation tokens.

SlugFest showed that a secure short-lived credential can still be abused when the identity binding behind it relies on a reusable name rather than an immutable identifier.

Why AI Coding Agents Increase Exposure

Bloom’s research also focused on the growing role of AI coding agents in package installation. The company found that a typical endpoint installs around 70 packages a month through AI agents, while developer systems may install close to 350 packages per month.

These figures cover direct installations and do not include the additional dependencies pulled in by each package. Tools such as coding assistants and IDE-integrated agents can choose, install, and execute packages with little human review.

If a legitimate dependency is silently replaced with a malicious release, the agent may select the newest version and run its lifecycle scripts as part of a normal setup task. This makes package provenance, version pinning, and review of install-time scripts more important than ever.

The concern also connects with the AI coding agent security risks reported earlier this year, where manipulated content could influence an agent to run attacker-controlled commands.

In the SlugFest case, the dangerous step is not a prompt alone: it is the possibility that an agent installs a package that has been published through an apparently trusted release path.

Bloom reported the issue through GitHub’s HackerOne program on June 6, 2026. The issue was validated on June 9, and the researchers said a fix was implemented on October 2 after more than 120 days.

GitHub now makes newly created but unvalidated Trusted Publishing configurations expire after 48 hours. A configuration becomes validated only after its first successful publish, which then binds it to the repository’s immutable identity.

GitHub also blocks Trusted Publishing tokens triggered by issue_comment events, in addition to its existing restriction on pull_request_target events.

Maintainers using affected workflows should move publishing to safer events, such as push, release, or workflow_dispatch. The current npm Trusted Publishing documentation confirms that a new configuration must complete its first successful publish within two days or it will expire.

Package maintainers should review every Trusted Publisher configuration, verify that each linked GitHub repository is still under their control, and remove and recreate bindings after a repository rename, deletion, or transfer.

Teams should also monitor unexpected release activity, pin dependency versions where practical, and review provenance attestations carefully.

As the ChainDrop trusted publishing incident demonstrated, valid provenance can show where a package was built, but it does not prove that the source repository, account, or build environment was safe.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post npm Trusted Publishing Flaw With 10 Million Downloads Exposes 1,500+ Packages to Malicious Takeover appeared first on Cyber Security News.