GitHub fixes npm flaw that exposed over 1,500 packages to hijacking

What researchers discovered

Security researchers at Bloom Security found a loophole in npm's trusted publishing system. This system was meant to make publishing packages safer by letting developers use short-lived tokens instead of long-term passwords. But the researchers found that, in some cases, attackers could publish new versions of someone else's package without needing to steal any credentials. The flaw affected over 1,500 npm packages, which had been downloaded more than 10 million times, according to The Hacker News↗ (opens in a new tab).

How the attack worked

The problem was with how npm trusted publishing identified which GitHub repository was allowed to publish a package. Instead of using a permanent, unique ID for each repository, it relied on the repository's name and owner (called a "slug"). If a repository was renamed, deleted, or transferred, someone else could claim the old slug. If the trusted publishing configuration had not yet been used to publish a version, an attacker could set up a new repository with the same slug and use it to publish a new version of the package. This would let them push malicious updates under the legitimate package name, inheriting its reputation and user base.

GitHub's response and changes

GitHub, which owns npm, has now changed the rules for trusted publishing. Any new trusted publishing configuration must be used to publish a package within 48 hours, or it will expire. Once the first publish is successful, the configuration is validated and tied to the repository's permanent ID. If the repository is renamed or transferred, a new trust relationship must be created. This change is meant to stop attackers from claiming old slugs and using them to hijack packages.

GitHub also updated npm to reject publishing tokens from certain GitHub Actions events that could be abused, such as issue comments, in addition to the existing restrictions.

The risk for developers and users

The attack, called "SlugFest" by researchers, could have led to widespread supply chain attacks. If a popular package was hijacked, any project or developer who relied on it could have unknowingly installed malicious code. The risk was even higher for teams using AI agents to manage dependencies, as these tools often fetch the latest version of a package without checking its source.

Developers who maintain npm packages are advised to:

• Audit their trusted publisher configurations and make sure the listed repository slug is still under their control.
• Delete and recreate trust bindings if a repository has been renamed, transferred, or deleted.
• Monitor for unexpected npm publish events.

Lessons for the wider software supply chain

This incident highlights a recurring problem in software supply chains: trust is often based on human-readable names, which can change or be reused. Security researchers warn that any system relying on such names, rather than permanent identifiers, is at risk of similar attacks. The findings echo earlier research into other software marketplaces, where attackers could hijack extensions by claiming abandoned names.

What happens next

At the time of writing, only The Hacker News has reported these findings, and there is no public statement from GitHub or Microsoft. Developers should stay alert for further updates and review their own package publishing setups to reduce risk.