npm Trusted Publishing Flaw: Was Your Package Exposed?

A flaw disclosed on October 13, 2026 by security researchers at Bloom Security shows that npm's Trusted Publishing feature bound a package's publishing trust to a GitHub repository's owner/repo name rather than its permanent, unchangeable numeric repository ID. Because repository names can be freed up — by a rename, a transfer, a deletion, or an abandoned GitHub account — researchers found that anyone who claimed that freed name could potentially set up a matching GitHub Actions workflow, mint a legitimate OpenID Connect (OIDC) token, and exchange it with npm for a credential that publishes new versions of someone else's real package. No stolen token or compromised account was required. Researchers identified more than 1,500 npm packages with a combined 10 million-plus downloads that had Trusted Publishing configured against a name-based binding, dubbing the flaw "SlugFest." GitHub shipped a fix on October 2, 2026, and tightened things further around the October 13 disclosure. Here is what actually happened, who was exposed, what changed, and what maintainers should check right now.

What is npm Trusted Publishing?

Trusted Publishing is npm's answer to a long-running supply-chain problem: long-lived npm access tokens sitting in CI/CD secrets, where a single leak can let an attacker publish a malicious version of a popular package. Instead of a static token, Trusted Publishing lets a CI workflow — typically GitHub Actions, or GitLab CI/CD — authenticate to npm using a short-lived OpenID Connect (OIDC) token generated fresh for that specific workflow run. npm exchanges that token for a short-lived publishing credential, and no npm secret ever has to live in your repository or CI environment.

npm's own documentation describes the setup: a maintainer registers a "trusted publisher" for a package on npmjs.com by entering the GitHub organization/user, repository name, and workflow filename; the workflow is granted id-token: write permission; and from then on, npm publish from that exact workflow succeeds without any npm token at all. The feature follows the OpenSSF's Trusted Publishers standard, the same model pioneered by PyPI in 2023 and later adopted by RubyGems, crates.io and NuGet. npm made Trusted Publishing generally available in July 2025 as part of a broader security push GitHub announced that September, following a wave of npm supply-chain attacks.

What is the SlugFest flaw?

SlugFest is the name Bloom Security's researchers gave to the gap they found in how npm validated a Trusted Publishing binding. When a maintainer configures a trusted publisher, npm stores the GitHub owner/repo string — essentially the "slug" in a URL like github.com/owner/repo — rather than resolving it immediately to GitHub's internal, permanent numeric repository ID. npm's own documentation acknowledges a version of this gap directly: "npm does not verify your trusted publisher configuration when you save it" — the binding is only checked when a publish is actually attempted.

The problem is that an owner/repo name is not a permanent identity. GitHub repository and account names can be freed up in several ordinary ways: a maintainer renames a repo, transfers it to a new organization, deletes it outright, or simply abandons the GitHub username tied to it. Once that name is free, anyone can register a new GitHub repository or account under the exact same slug. If that slug still matched an npm package's Trusted Publishing configuration, the new owner's GitHub Actions workflow could generate an OIDC token that, on paper, looked identical to the legitimate maintainer's — because npm was still checking the name, not the underlying repository's unchangeable identity.

How the attack worked, step by step

Based on the disclosed research, the attack chain required no credential theft at all:

1. A target npm package has Trusted Publishing configured against a GitHub owner/repo name and a workflow filename.
2. That repository name (or the account that owns it) becomes available — through a rename, transfer, deletion, or an expired/renamed GitHub account.
3. An attacker registers a new GitHub repository (or account) under the exact freed name, and adds a GitHub Actions workflow file matching the filename npm expects.
4. Running that workflow, GitHub issues a legitimate OIDC token scoped to "owner/repo" — which now points at the attacker's repository, not the original one.
5. npm exchanges that token for a publishing credential, because its stored configuration still matches the name string, and the attacker publishes a new version of someone else's real, trusted package — inheriting its reputation, its download count, and the trust of everyone who depends on it.

Because the attacker never needs a leaked token, a phished maintainer, or a compromised npm account, the technique sidesteps essentially all of the protections — 2FA, short-lived tokens, granular scopes — that GitHub's broader npm security push was built around. It specifically targets the trust relationship itself.

Who was affected?

Bloom Security's researchers reported finding more than 1,500 npm packages whose Trusted Publishing configuration was bound to a GitHub repository or owner name rather than an immutable ID, with those packages accounting for more than 10 million combined downloads. That figure covers only the subset of the npm ecosystem that had adopted Trusted Publishing at all (a feature only generally available since July 2025), not npm as a whole. The researchers reported no confirmed instance of the technique being exploited against a real package before disclosure, and said they had not published the specific list of affected package names.

In practice, exposure hinged on whether a package's bound GitHub owner/repo name could plausibly become available — for example, through a maintainer renaming a personal account, a project moving to a new GitHub organization during a reorg, or an old side-project repository being deleted once a package matured. Packages maintained inside large, stable organizations with no history of renames or transfers were lower-risk by nature, even before GitHub's fix shipped; packages maintained by individual developers, or that had changed hands or names at any point, were the more plausible targets.

Timeline: from report to fix to disclosure

GitHub's own changelog entry does not mention Bloom Security or SlugFest by name; it states only that the change "limits the risk of trusting a repository or project name that changes ownership." Several outlets covering the October 13 disclosure reported that researchers had flagged the issue to GitHub's HackerOne program months earlier, in June 2026, and that the October 2 fix followed an extended gap in vendor responses. Pandromeda was unable to independently verify the exact report date or response timeline beyond GitHub's own published changelog date; readers should treat any report-to-fix duration cited elsewhere as unconfirmed pending a primary statement from GitHub or Bloom Security. No CVE identifier had been publicly assigned to the issue as of publication.

What GitHub actually changed

According to GitHub's own changelog, published October 2, 2026, two specific changes now apply to every npm Trusted Publishing configuration:

• 48-hour validation window. A newly created Trusted Publishing configuration that has not yet been used for a successful publish now expires 48 hours after it is created, and can no longer authorize a publish after that. The first successful publish "validates" the configuration, binding it to the repository's immutable identity going forward and exempting it from expiry. Changing the bound repository or project identity requires setting up a new trust relationship, which starts a fresh 48-hour window; ordinary edits to an already-validated configuration do not reset the clock. Expired, unvalidated configurations stay visible in a package's trusted-publisher settings, but no longer count toward npm's per-package limit, and a maintainer who wants to use that binding again has to recreate it.
• Blocking a risky GitHub Actions trigger. npm now rejects Trusted Publishing tokens generated from GitHub Actions issue_comment events, the same way it already rejected tokens from pull_request_target — both event types can be triggered by an outside contributor's comment or pull request rather than by a trusted maintainer action, making them a known weak point for OIDC-based publishing setups. GitHub's guidance is to move publishing workflows to a trigger such as push, release, or workflow_dispatch instead.

Neither change alters the fundamental fact that npm still keys a validated configuration's trust to a repository's identity rather than re-checking a live name match on every publish going forward — but the 48-hour expiry specifically closes the window where a configuration sits unvalidated against a name that could later be reclaimed by someone else.

Is my npm package safe? How to check

If you maintain a package that uses npm Trusted Publishing, there are a few concrete things worth checking today:

• Open your package's Trusted Publisher settings on npmjs.com and confirm the listed GitHub owner, repository name, and workflow filename still point to a repository you actively control.
• Check whether that repository has ever been renamed, transferred, or recreated. If the owner account or repo name was ever freed and reclaimed, your configuration's trust may have been resting on a name rather than the repository you think it is.
• Confirm your configuration is validated, not dangling. npm's documentation notes a new configuration must complete its first successful publish within the 48-hour window; if you set one up and never published through it, it will now have expired and needs to be recreated.
• Review which GitHub Actions events can trigger your publish workflow. If your workflow listens on issue_comment or pull_request_target, npm will now reject the resulting token outright — move the trigger to push, release, or workflow_dispatch.
• Check published versions and provenance. npm generates provenance attestations automatically for public packages published this way; comparing them against your own release history can surface a publish you didn't make.

As a dependency consumer rather than a maintainer, there's no indicator baked into a package page that tells you whether it was ever exposed to SlugFest specifically — this was a configuration-side gap, not a published-malware event, and researchers reported no confirmed exploitation. The practical takeaway for consumers is the same general hygiene that applies after any registry-trust disclosure: pin dependency versions, review diffs on major or unexpected version bumps for sensitive dependencies, and keep lockfiles under source control so an unexpected publish doesn't silently flow into your build.

What maintainers should do now

Beyond the immediate audit above, a few habits reduce exposure to this class of issue going forward: avoid letting a repository that still has an active Trusted Publishing configuration sit abandoned, renamed, or transferred without first removing or re-validating that configuration; treat a GitHub organization or account rename as a trigger to re-check every package's trusted publisher bindings, not just update links; and keep an eye on npm's own documentation and changelog for further hardening, since the October 2 change is an incremental mitigation rather than a structural rework of how the binding is keyed. Teams running larger numbers of packages under one organization may also want to standardize workflow filenames and restrict who within the org can rename or transfer repositories at all, since that administrative action is now the practical trigger for this entire attack class.

It's also worth noting Trusted Publishing itself remains a significant security upgrade over long-lived tokens — eliminating a static secret from CI entirely closes off a much larger and more commonly exploited class of attacks. SlugFest is a flaw in how the trust relationship was keyed, not an argument against adopting OIDC-based publishing; if anything, the practical fix is to audit and re-validate configurations rather than to revert to tokens. Teams comparing package-manager tooling more broadly as part of that review may find it useful to read how npm compares with pnpm, Yarn and Bun on supply-chain-relevant features, or the background on Node.js 26 becoming active LTS later this month, since several of these protections ship at the runtime and registry-tooling level together.

Why this matters beyond one flaw

SlugFest lands amid a string of npm supply-chain incidents GitHub has been responding to since at least September 2025, when a wave of compromised packages prompted the broader security plan that introduced Trusted Publishing in the first place. The pattern across these incidents is consistent: attackers increasingly target the trust and automation layer around package publishing rather than trying to directly compromise a maintainer's machine or credentials. A name-based trust binding is exactly the kind of subtle, structural gap that fits that pattern — it doesn't require breaking any cryptography or stealing any secret, just understanding that a GitHub repository's name and its underlying identity are two different things.

Researchers covering the disclosure also raised a related concern worth flagging as unconfirmed, forward-looking context rather than established fact: as AI coding agents increasingly resolve and install npm dependencies autonomously, often defaulting to the latest available version without a human reviewing where a package update came from, any gap that lets an attacker slip a malicious version into a trusted package's version history becomes more consequential, not less. That risk applies broadly to supply-chain trust gaps generally, and reinforces why maintainers auditing dependency provenance is now a meaningfully higher-value habit than it used to be. Readers newer to how these attacks typically operate at the network and trust level may also find background in Pandromeda's explainer on man-in-the-middle attacks useful for the broader category of "trust the wrong thing" exploits, even though SlugFest itself is a registry-configuration flaw rather than a network attack.

What happens next

GitHub's October 2 changelog entry is live now, meaning the 48-hour expiry and the issue_comment token rejection already apply to every npm Trusted Publishing configuration, new and existing. There is no indication, based on GitHub's own published materials, of a further structural change planned to how trust bindings are keyed beyond the validation-and-expiry mechanism already shipped. Maintainers who haven't checked their Trusted Publishing settings since before October 2 should do so this week: confirm every configuration is validated, confirm the bound repository still belongs to you, and confirm your publish workflow isn't triggered by an event GitHub Actions treats as low-trust. For now, there's no evidence SlugFest was exploited against a real package before GitHub's fix shipped — but the flaw is a reminder that in registry trust systems, a name and a permanent identity are not the same thing, and treating them as interchangeable is exactly the gap attackers look for.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage