Over 1,500 npm packages exposed by Trusted Publishing validation flaw

A flaw in npm’s Trusted Publishing mechanism could allow attackers to hijack legitimate software packages by reclaiming abandoned GitHub repository names, potentially exposing millions of package downloads to supply-chain attacks. Researchers at Boom Security identified more than 1500 potentially vulnerable npm packages, including security scanners, authentication tools, and cryptographic packages. The vulnerability, dubbed SlugFest, came from npm’s reliance on human-readable GitHub repository names to verify trusted publishers rather than the repositories’ permanent numeric identifiers. This could allow an attacker to inherit a package’s publishing trust by claiming a repository name that its original owner had abandoned. The issue is now fixed, Boom Security researcher Golan Myers told CSO. “The npm team confirmed that a fix had been shipped on October 2, introducing a 48-hour expiry for unvalidated Trusted Publishing configurations,” he said. Myers said Boom has not observed active exploitation in the wild, but confirmed that the flaw was successfully used to publish a new version of an existing npm package under their own controlled testing conditions. The fix addresses the exposure associated with unvalidated configurations, although maintainers still need to review their existing trust relationships, Boom wrote in a blog post shared with CSO ahead of its publication on Tuesday. A reclaimed repository name enabled package publishing npm’s Trusted Publishing allows package maintainers to publish releases through automated workflows using OpenID Connect (OIDC), avoiding long-lived publishing credentials. However, Boom found that npm’s trust configuration relied on the GitHub repository’s owner/repository name instead of its immutable repository ID. When a repository is renamed, transferred, or deleted, its former name may become available for another user to claim. An attacker could create a repository at that address and configure a GitHub Actions workflow with the expected filename. Because npm checked the repository name and workflow filename without verifying the permanent repository ID, the attacker could potentially obtain a valid publishing credential for a package they did not own. The researchers demonstrated the attack against a researcher-controlled package, publishing a new version from a GitHub repository belonging to a different organization. The attack did not require compromising the legitimate maintainer’s GitHub or npm account or stealing their credentials. Their registry-wide scan identified more than 1500 vulnerable packages with over 10 million combined downloads and more than one million downloads per month. One package accounted for over 200,000 monthly downloads, according to Boom. AI agents amplify the supply-chain risk Boom argues that AI coding agents can accelerate the distribution of malicious dependencies because they increasingly select and install software packages with limited human intervention. Across dozens of organizations, the researchers measured approximately 70 agent-installed packages per endpoint each month, rising to around 350 on developer machines. These figures cover direct installations and exclude transitive dependencies. A malicious release could execute attacker-controlled code through an installation hook when developers or CI systems install the compromised package. AI agents could introduce such a dependency without a developer explicitly selecting it. “A hijacked package doesn’t need to find a developer anymore,” Myers said. “It only needs to be the package an agent chooses.” Apart from GitHub addressing the problem by making unvalidated Trusted Publishing configurations expire after 48 hours, npm also tightened its safeguards by rejecting trusted-publishing tokens issued through GitHub Actions’ issue_comment events, alongside the existing restriction on pull_request_target events. Additionally, Boom recommended that maintainers audit their Trusted Publishing configurations, verify that each trusted repository name still resolves to a repository under their control, and remove and recreate bindings where necessary. The researchers also advised security teams to audit software dependencies and tools used across their environments and enforce controls over what developers and AI agents are permitted to install.