The leftover name is not a trusted publisher

The door that still opens after you move

Imagine you change the shop locks, transfer the lease, and leave the old sign on the curb. A week later someone hangs that same sign on a different door, walks in, and starts shipping under your brand. Nobody stole your keys. They only claimed the leftover name.

That is the shape of the Trusted Publishing flaw Bloom Security disclosed this week. The feature was meant to replace long-lived publish tokens with short-lived identity from CI. The trust still hung on a label that could be abandoned and reclaimed.

When the label outlives the owner

Trusted Publishing, generally available since July 2025, lets a maintainer tell npm which GitHub repository and workflow file may publish a package. When that workflow runs, GitHub issues a signed identity token, and npm exchanges it for a publish credential that expires within minutes. That design is good. Long-lived tokens are a mess.

The weak spot, Bloom found, was how npm recorded the repository. It stored the owner/repo string GitHub calls a slug. GitHub also assigns every repository and owner a permanent numeric ID that survives renames and transfers, and it puts both IDs in the token. npm did not check them. Once a maintainer renamed, transferred, or deleted the bound repository, or the owner account was renamed or deleted, the old slug could become free. Anyone who created a repository at that name, added a workflow file with the matching filename, and ran it could receive a publish credential for a package they did not own.

Bloom called the pattern SlugFest in CSO Online's coverage. Researchers ran the attack end to end on packages and repositories they controlled, publishing from a second organization's repository that had claimed the freed slug. A release published that way also carried a valid provenance attestation naming the attacker's repository. Bloom's registry-wide scan found more than 1,500 potentially exposed packages with more than 10 million combined downloads and more than one million downloads a month. One package alone accounted for more than 200,000 monthly downloads, according to CSO Online's report of Bloom's findings. Bloom is not publishing the affected package names.

GitHub retires some repository names after heavy clone activity when an owner account is renamed or deleted, which protects part of the surface. Bloom says it only counted claimable leftover slugs. Golan Myers, a Bloom security researcher, told Help Net Security it is unknown whether anyone exploited the flaw in the wild outside the team's controlled tests.

The October 2 fix, and what still needs a human

GitHub announced on October 2 that unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing. The changelog's stated goal is blunt: limit the risk of trusting a repository or project name that changes ownership. After the first successful publish, the configuration becomes validated and exempt from expiry. npm's documentation now says that first successful publish binds the configuration to the repository's immutable identity. Changing the repository or project identity requires a new trust relationship with a fresh 48-hour window.

npm also now rejects trusted-publishing tokens from GitHub Actions issue_comment events, on top of the existing pull_request_target restriction. Publishing should move to permitted events such as push, release, or workflow_dispatch.

Bloom reported the issue through GitHub's bug bounty program on HackerOne on June 6. GitHub validated it on June 9. Bloom told Help Net Security its last reply came on July 8, and that later follow-ups went unanswered until the October 2 changelog. A GitHub spokesperson told Help Net Security the company learned of the event through the bug bounty program, validated the report, and shipped fixes. GitHub's public statement does not say whether older configurations that published before the change were bound retroactively. Maintainers still need to audit what they trust.

Bloom also argues that coding agents widen the blast radius because they install packages with less human review. Across dozens of organizations, the researchers measured roughly 70 agent-installed packages per endpoint each month, rising to around 350 on developer machines, not counting transitive dependencies. Myers's line in the CSO coverage is the operations point: a hijacked package does not need to find a developer anymore. It only needs to be the package an agent chooses.

Clearwater's reminder that local cyber work is growing up

While the registry story played out nationally, Tampa Bay's cybersecurity lane kept moving.

On October 12, Tampa Bay Business Journal reported that Guardare, a Clearwater cybersecurity startup, closed a follow-on round backed by Florida investors, including regional players. Dealroom's same-day note puts the round at $5.6 million, says the financing pushes Guardare's total raised past $10 million, and says the company plans to use the capital to expand into EMEA (Europe, the Middle East, and Africa). TBBJ's headline frame is Guardare topping $10 million and eyeing that overseas growth. The paper's story also names CEO and co-founder Lars Letonoff.

That is not a claim that Guardare is connected to npm's Trusted Publishing fix. It is a local signal: Florida backers are still funding companies whose job is to keep identity, access, and monitoring from becoming an afterthought. When the national tooling story is about who is allowed to publish under your name, a region that keeps investing in cybersecurity is paying attention to the right class of problem.

What shops should check this week

Most companies do not maintain an npm package with Trusted Publishing. Plenty of them do depend on open-source packages, CI workflows, and internal tools that publish or update themselves under a trusted label. The habit that matters is the same.

Do not confuse a familiar name with a locked identity. If a repository was renamed, transferred, or deleted, ask whether any publish trust still points at the old slug. If an agent or a workflow can install updates without a named reviewer, ask who owns the exception when the package or the publisher looks wrong. If your own portals, phone systems, or integrations can ship changes on a matching label alone, put a human stamp on the trust relationship before you trust the next update.

A short checklist for this month

You can start without a new platform. Grab the people who own CI, package updates, and production deploys.

1. List what can publish. Write down every path that can push a package, image, site, or config change: GitHub Actions, other CI, npm tokens, deploy keys, and agent-driven installs.
2. Check the names still resolve. For any Trusted Publishing or OIDC trust binding, confirm the repository or project name still points at something you control. Delete and recreate bindings that trail a rename or transfer.
3. Prefer immutable identity. Where the platform offers a permanent repository or project ID, use it. Do not leave trust hanging only on a slug that can be abandoned.
4. Time-box unproven trust. Treat a new publisher config like a probation period. If the first successful publish has not happened, do not leave the door open indefinitely.
5. Name who reviews the exception. When an agent or a workflow wants to install or ship something unfamiliar, name the person who approves it and where that approval is recorded. "The team" is not an owner.

Where Keel fits

I write for Keel Automation, a Tampa Bay automation agency founded by Cole Junck. Keel has no partnership or relationship with Bloom Security, GitHub, npm, Guardare, Tampa Bay Business Journal, Dealroom, CSO Online, or Help Net Security, and nothing in this article is an endorsement from any of them.

The work we do sits next to the trust problem these stories describe. We build user friendly portals that give a business a one-stop-shop for its processes, integrations that connect the phone system, CRM, website, and accounting tools a team already uses, and SI (Super Intelligence) agents and workflows that pull the right context to a named owner and keep a record of who approved what. The goal is simple: fewer leftover labels with open doors, clearer ownership, and updates that only ship when the right person says so.

If your publish paths still trust a name that might have moved, you can reach us at (813) 902-4763.

Sources

1. Mirko Zorz, "npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover," Help Net Security, October 13, 2026. https://www.helpnetsecurity.com/2026/10/13/slugfest-npm-trusted-publishing-flaw/
2. Shweta Sharma, "Over 1,500 npm packages exposed by Trusted Publishing validation flaw," CSO Online, October 13, 2026. https://www.csoonline.com/article/4234229/over-1500-npm-packages-exposed-by-trusted-publishing-validation-flaw.html
3. GitHub Changelog, "Unvalidated npm trusted publishing configurations now expire," October 2, 2026. https://github.blog/changelog/2026-10-02-unvalidated-npm-trusted-publishing-configurations-now-expire/
4. npm Docs, "Trusted publishing for npm packages" (trusted publisher configuration expiry / immutable identity). https://docs.npmjs.com/trusted-publishers/
5. Anjelica Rubin, "Guardare tops $10 million with follow-on round of financing, eyes EMEA growth," Tampa Bay Business Journal, October 12, 2026. https://www.bizjournals.com/tampabay/news/2026/10/12/guardare-follow-on-round.html
6. Dealroom News, "Guardare tops $10M with $5.6M follow-on round, targets EMEA," October 12, 2026. https://dealroom.co/news/161812-guardare-tops-10m-with-5-6m-follow-on-round-targets-emea/