npm October 2026 SlugFest Flaw Explained: How Reclaimed Repo Names Could Publish

Until 2 October 2026, if an npm trust rule had never been used, whoever owned the GitHub name it pointed at could publish your package. GitHub names can change hands: when an organisation is renamed, someone else can register the old name.

That is the npm trusted publishing vulnerability that Bloom Security disclosed on 13 October 2026 and named SlugFest. A slug is the short owner/repo name of a GitHub repository, and npm treated it like an identity.

Picture a common setup. A small team maintains an open-source npm package that draws a UPI payment button on a few hundred shop websites. UPI is India's instant bank-to-bank payment system. The setup is made up, but the flaw is real.

Those shops take about 2 crore rupees (20 million rupees) a day through the button. In May, a maintainer added a trusted publisher on npm for the repository OLDORG/pay-widget and the workflow file release.yml. The first automated release kept slipping, so that rule never published anything.

In August, the team renamed its GitHub organisation from OLDORG to NEWORG. Nobody updated the npm rule. When the SlugFest write-up appears, the team asks one question: who can own the name OLDORG today?

You need five words: OIDC token, trusted publisher, slug, repository ID and provenance.

• OIDC token. OpenID Connect, or OIDC, is a standard way for one system to vouch for another. GitHub Actions, GitHub's built-in CI service, can give a running job a signed, short-lived token that names its repository and workflow.
• Trusted publisher. A rule on an npm package that says: accept releases from this repository and this workflow file. Bloom calls it a binding and GitHub calls it a configuration. This guide says binding.
• Slug. The readable owner/repo name, such as OLDORG/pay-widget. Owners can change it, and someone else can take a freed name.
• Repository ID. A number GitHub gives every repository, carried in the token as repository_id. It stays the same through renames. A new repository created at an old name gets a new number.
• Provenance. A signed record of where and how a package was built. npm creates it with Sigstore, a public signing service that keeps a public log.

It is a gap in how npm decided who may publish. Until a binding had published once, npm compared names with the binding: the owner/repo name and the workflow file name in the token. According to Bloom, it recorded the permanent repository IDs only after that first publish, which npm calls validation.

Bloom Security reported the flaw on 6 June 2026 through GitHub's HackerOne programme, a service where outside researchers report bugs. GitHub's changelog describes the change without naming the flaw, so the mechanism below comes from Bloom.

Bloom scanned the registry and found more than 1,500 exposed packages, with over 10 million total downloads. It has not published the list, saying the issue is still prevalent.

Your CI workflow, the job that builds and releases your code, proves who it is with a short-lived OIDC token. The npm registry, the server that stores packages, checks the token against the binding. Then it swaps the token for a short-lived publish credential.

No long-lived npm token sits in your repository secrets. To set it up, you add the repository and workflow file name on npm, and give the workflow the id-token: write permission. That permission lets the job ask GitHub for an OIDC token.

The token carries claims, which are named facts about the run. GitHub documents claims such as repository, workflow and event_name, plus the numeric repository_id and repository_owner_id.

Publishing through trusted publishing also creates provenance automatically. npm's docs scope this to public packages published from public repositories.

A name is a label that people can change or give up. The ID stays with the repository, so only the ID proves it is still the same repository.

Think of a shop sign and the shop owner's PAN, the permanent tax number every Indian taxpayer gets. The sign is the slug: whoever takes over the premises can put up the same sign. The PAN is the repository ID: a newcomer gets a different one.

Where the picture breaks: a PAN names a person, while repository_id names one repository. A transferred repository keeps its repository_id, so WorkOS advises checking repository_owner_id as well to catch transfers.

Who can claim a freed name depends on what changed. Bloom notes that renaming or deleting the owner account, an organisation or a username, frees the owner name for anyone to register. GitHub's docs say the same for a renamed organisation.

A repository renamed, moved or deleted inside an account you still control frees the name only to people who can create repositories there.

GitHub does retire some old names for good. After an organisation rename, GitHub permanently retires the old owner/repo name of some public repositories. That covers a repository with over 100 clones or 100 Actions uses in the week before, or with a Marketplace action.

WorkOS notes that this retirement rule narrows the exposed set somewhat. Repositories below those thresholds, like many small packages, get no such protection.

Bloom notes that PyPI's Warehouse, the software behind Python's package registry, already avoids this. It looks up the IDs for a name when the trust rule is set up, then stores them.

npm stored the IDs too, but only after the first successful publish. Before that, the team's binding was just a name and a file name. Anyone holding both could pass the check.

By re-creating the old name and running a workflow with the expected file name. Bloom describes the steps, and none of them needs a stolen password or token.

The precondition is narrow. The binding must point at a name that is now free, and it must never have published a version. The team's binding fits both.

What a binding stores, seen from the npm CLI

You can see the weak key yourself, with no npm account. A dry run of npm trust in npm 11.21.1 prints what it would ask npm to store and stops before any request. This is the output we got:

$ npm trust github demo-pkg --repo OLDORG/pay-widget --file release.yml --allow-publish --dry-run --json
{
  "package": "demo-pkg",
  "file": "release.yml",
  "repository": "OLDORG/pay-widget",
  "permissions": [
    "createPackage"
  ]
}

What just happened? The request holds a package name, a workflow file name and an owner/repo string, with no repository ID. createPackage is the registry's name for the --allow-publish permission.

Bloom reports that the registry adds the IDs only after the first successful publish. Without --json, the same command warns that anyone with write access to that GitHub repository can publish the package.

Bloom adds that AI coding agents now pick and install dependencies on their own, often without a human checking. A hijacked release could reach many machines that way.

GitHub made unvalidated npm trusted publishing configurations expire 48 hours after creation. A configuration becomes validated, and exempt from expiry, after its first successful publish.

• Expiry. A binding that has not published within 48 hours can no longer authorise publishing. Expired bindings stay visible in the package's trusted publisher settings, and you recreate one to start a fresh window.
• Identity changes. Pointing a binding at a different repository or project needs a new trust relationship, with its own 48-hour window. Ordinary edits do not restart the clock.
• Event block. npm now rejects tokens from GitHub Actions issue_comment events, which run when someone comments on an issue or pull request. Tokens from pull_request_target events were already rejected.

A pull_request_target run uses the main repository's context even for pull requests from forks, which is why GitHub's docs warn against running untrusted code there.

npm's documentation states the same deadline as 2 days and adds the key detail. The first successful publish binds the configuration to the repository's immutable identity. Bloom says that is when the numeric IDs get stored.

Pause and predict: the team's binding was created in May and never used. Did the 2 October change retire it? Hold that question for two paragraphs.

The expiry shrinks the risk but keeps the same weak key, according to WorkOS's analysis. A new binding still starts from a name, so for up to 48 hours it trusts whoever holds that name.

WorkOS also notes that the changelog does not say what happened to bindings that were already unvalidated on 2 October. That is exactly the team's case, and as of 19 October 2026 the changelog still does not say.

For the team, the expiry may already have retired the May binding. Nobody wants to bet 2 crore rupees of daily payments on a maybe, so the team checks.

A related change on GitHub's side

Since 15 July 2026, GitHub's OIDC subject claim has carried the owner ID and repository ID for repositories created after that date. Repositories renamed or transferred after it switch too, and older ones can opt in.

Neither GitHub's npm changelog nor npm's docs say npm uses this claim, as of 19 October 2026. GitHub's docs also say the change does not reach GitHub Enterprise Server.

No. Provenance proves where a package was built, not that it was built where you expected. npm's provenance documentation says it does not guarantee the package has no malicious code.

Bloom notes that the attacker's release would be signed by Sigstore against the attacker's repository. npm audit signatures checks that registry signatures and attestations, the signed provenance records, are valid. In npm 11.21.1 it does not compare the repository with one you expected.

Read the repository ID from the provenance certificate

The registry serves each version's attestations as JSON. Each provenance record is signed with a short-lived certificate from Fulcio, Sigstore's certificate authority. This script prints the repository fields from that certificate for semver 7.7.3.

import base64
import json
import urllib.request

from cryptography import x509  # pip install cryptography

PACKAGE, VERSION = "semver", "7.7.3"
FIELDS = {"1.3.6.1.4.1.57264.1.12": "repository",
          "1.3.6.1.4.1.57264.1.15": "repository_id",
          "1.3.6.1.4.1.57264.1.17": "repository_owner_id"}


def der_text(raw):
    # DER string: tag byte, then a short or long-form length, then text
    size, start = raw[1], 2
    if size & 0x80:
        count = size & 0x7F
        size = int.from_bytes(raw[2:2 + count], "big")
        start = 2 + count
    return raw[start:start + size].decode()


url = ("https://registry.npmjs.org/-/npm/v1/attestations/"
       + PACKAGE + "@" + VERSION)
with urllib.request.urlopen(url) as resp:
    attestations = json.load(resp)["attestations"]

for att in attestations:
    if not att["predicateType"].startswith("https://slsa.dev/provenance/"):
        continue
    vm = att["bundle"]["verificationMaterial"]
    cert = vm.get("certificate") or vm["x509CertificateChain"]["certificates"][0]
    cert = x509.load_der_x509_certificate(base64.b64decode(cert["rawBytes"]))
    for ext in cert.extensions:
        name = FIELDS.get(ext.oid.dotted_string)
        if name:
            print(name + ":", der_text(ext.value.value))

We ran it on 19 October 2026 and got this output:

repository: https://github.com/npm/node-semver
repository_id: 1357199
repository_owner_id: 6078720

Here is what those lines mean. Sigstore's Fulcio documentation maps these certificate fields to GitHub's repository_id and repository_owner_id token claims. A release built at a reclaimed name would carry the new repository's ID.

Compare it with your real repository's ID: the id GitHub's API returns for NEWORG/pay-widget, or an earlier release that has provenance. Certificates from early 2023, such as sigstore 1.0.0's, lack these fields, so the script prints nothing for them.

The same IDs also appear inside the provenance statement, but npm 11.21.1 copies those from environment variables during the build. Prefer the certificate. The script only reads it; npm audit signatures does the verifying.

Check every binding, recreate any that point at old names, and publish once through each new one. These steps follow Bloom's and WorkOS's advice.

1. 1

   Check your npm version

   Run npm --version. npm's docs ask for npm 11.15.0 or later for npm trust, as of 19 October 2026. On npm 10 the command prints: Unknown command: "trust".

2. 2

   List your bindings

   Run npm trust list PACKAGE for each package. It prints each binding's id, type, workflow file and repository.

3. 3

   Confirm you own every name

   Check that each owner/repo name is still a repository you control, under the same name.

4. 4

   Revoke and recreate stale bindings

   Run npm trust revoke PACKAGE --id=TRUST_ID with the id from the list. Then create a binding for the current name with npm trust github and --allow-publish.

5. 5

   Publish straight away

   Release once through the new binding so it validates and stores the repository's immutable identity.

6. 6

   Treat renames as revocation

   Remove the binding before you rename, transfer or delete a bound repository, not after the old name is freed.

7. 7

   Watch for surprise releases

   Alert on any publish you did not start.

What npm trust list does not show

The npm trust command first shipped in npm 11.10.0, per GitHub's February 2026 changelog. Version 11.15.0 added the --allow-publish and --allow-stage-publish flags, and from that version the CLI refuses to create a binding without one. The docs do not say why they ask for 11.15.0.

We read the command's source in npm 11.21.1 and 12.2.0. npm trust list prints id, type, file, repository, environment and permissions. It does not print whether a binding is validated or expired. GitHub's changelog says expired bindings stay visible in the package's trusted publisher settings on npmjs.com; we could not check how that page labels them.

A name check that misses renames

The naive check asks GitHub's API for the ID behind each name and compares it with the ID you noted. That is wrong for renames. GitHub's API still redirects requests for a renamed or moved repository's old name, so the old name returns your ID. GitHub's rename docs say API requests that use the old organisation's name return 404. In practice, repository requests are still redirected, as the next example shows.

Compare the name GitHub reports as well. This script does both, using GitHub's public API without a token.

import json
import urllib.error
import urllib.request

API = "https://api.github.com/repos/"

# Each binding's owner/repo name and the repository ID you noted
# when you created it (made-up values)
expected = {"OLDORG/pay-widget": 812345678}


def lookup(slug):
    try:
        with urllib.request.urlopen(API + slug) as resp:
            data = json.load(resp)
    except urllib.error.HTTPError as err:
        return None, "HTTP " + str(err.code)
    return data["id"], data["full_name"]


for slug, want in expected.items():
    got_id, name = lookup(slug)
    if got_id != want:
        print(slug, "DANGER: not your repository now:", got_id, name)
    elif name.lower() != slug.lower():
        print(slug, "STALE: GitHub redirects this name to", name)
    else:
        print(slug, "OK")

For the team's stale binding, the script prints: OLDORG/pay-widget STALE: GitHub redirects this name to NEWORG/pay-widget. A real case, as of 19 October 2026: GitHub's API answers the old name zeit/next.js with vercel/next.js, ID 70107786.

A new organisation with a different ID now holds the name zeit, yet the redirect still works because no zeit/next.js repository exists. The script would print STALE there, while an ID-only check expecting 70107786 would print OK.

A reclaimed name prints DANGER with a different ID. HTTP 404 means deleted or private, because GitHub answers 404 for a private repository when the request has no token. A deleted owner frees the name to anyone, so treat a 404 as stale until you know why.

HTTP 403 or 429 means you hit GitHub's rate limit, not a takeover. Wait, or send the request with a GitHub token.

The team's npm trust list run shows the old OLDORG binding. They revoke it, create one for NEWORG/pay-widget and ship version 2.4.1 through it that afternoon. Nobody had claimed the old name, so this ends as a cleanup.

Frame it as an authorisation bug, a mistake in deciding who may act. The system checked a name that can change hands, not an ID that cannot.

1. 1

   Describe the trust flow

   CI gets an OIDC token, npm checks it against a stored binding, then swaps it for a short-lived publish credential.

2. 2

   Point at the weak key

   Before the first publish, the binding matched only names, and names can be freed and claimed.

3. 3

   Walk through the attack

   Claim the freed name, add a workflow with the same file name, get a matching token and publish.

4. 4

   Compare the fixes

   GitHub now expires unused bindings after 48 hours. Bloom's proposal, pinning the repository ID at creation, would close that window too, if the name is still yours at creation.

5. 5

   Generalise the lesson

   Usernames, email addresses and domains can be reclaimed too. Key authorisation on IDs the system assigns and never reuses.