Engineering

Abandoned Code Is an Open Door

This month's npm Trusted Publishing flaw came down to names people left behind. Here's why every launch needs an owner and a maintenance plan, plus a one-afternoon audit.

Hari Gopal Sharma · 2026-10-16 · 6 min read

security software supply chain maintenance npm

This week's most instructive security story didn't involve a stolen password. It involved a name someone stopped using.

On October 13, Help Net Security reported on research from Bloom Security, which the researchers call SlugFest. npm's Trusted Publishing feature lets a GitHub repository publish new versions of a package without a stored token. The trouble was how npm recognised that repository: by its name (the "owner/repo" string GitHub calls a slug), not by GitHub's permanent numeric ID. If a maintainer renamed, transferred or deleted the linked repository, or renamed or deleted the owner account, someone else could register the old name, add a workflow file with the matching filename, and receive a credential to publish to a package they didn't own.

Bloom says more than 1,500 npm packages were exposed, with over 10 million total downloads. It ran the attack end to end on a package and repositories it controlled. Bloom says it is unknown whether anyone exploited it in the wild.

I've spent years in healthcare, cybersecurity and enterprise software, and this pattern is the one I see most often. Attackers don't always break in. Very often they walk through something the owner forgot they still had.

What actually went wrong

Strip away the jargon and the failure is simple. A package pointed at a GitHub repository by name. The maintainer moved on and the name became free, but the package kept trusting whoever held it next.

GitHub does retire the names of repositories with more than 100 clones in the week before an owner account is renamed or deleted, which protects some projects. Bloom says it accounted for that rule, and every package it flagged involved a name anyone could claim.

GitHub's October 2 changelog introduced a fix: Trusted Publishing configurations that haven't been validated by a first successful publish now expire after 48 hours. Help Net Security notes that GitHub's statement didn't say whether configurations already bound before the change were retroactively affected. Bloom also isn't publishing the list of affected packages, so you can't check against one.

That last point matters for business owners. You can't wait for a list. You need to know what you depend on.

It's been a busy fortnight for npm

SlugFest wasn't the only reminder this month.

On October 5, StepSecurity documented a malicious release of @subql/common, version 5.8.3. The project's release workflow had been changed to download a tarball from an outside domain and publish it in place of the real build. The payload ran at install and whenever the package was imported, and it went after `.env` files, cloud credentials, SSH keys and CI secrets. Other SubQuery packages whose version ranges could resolve to it were exposed too.

On October 8, Socket reported that tensorlake 0.5.144 had been published with a preinstall hook that launched a credential-stealing worm. It targeted npm, GitHub and cloud tokens, plus configuration files for AI coding tools, and tried to republish compromised versions of other packages tied to the victim's publishing identity.

Different mechanics, same lesson. Your software is made of other people's software, published through pipelines and accounts that someone has to keep watching.

Software needs an owner after launch day

Most of the businesses I talk to budget for building software. Far fewer budget for owning it. The launch goes well, the contractor moves on, and two years later nobody can say who has admin access to the GitHub organisation, which domain the old marketing site used, or whether that WordPress plugin still gets updates.

None of those things are bugs in the usual sense. They're technical debt with a security cost attached. Here's where I'd look first:

A launch should come with a maintenance plan: an inventory of what you run, a named owner for each piece, an update cadence, and an offboarding routine for people, accounts and repositories. That costs money, which is why I'd argue maintenance belongs in the budget from the first estimate, not as a surprise in year two.

A one-afternoon software estate audit

You don't need a security team for this. Sit down with your developer, or whoever built your product, and work through the list. Write the answers in a shared document, because the document is half the value.

Inventory

Ownership

Dependencies

Offboarding

Cadence

You'll probably find something. That's the point. Finding it on a quiet Friday is much cheaper than finding it in an incident report.

Where to go from here

If the audit turns up more than your team can comfortably own, that's normal. Most small companies grow their software estate faster than their ability to look after it. We help founders and operators build and maintain products with ownership, updates and offboarding planned from the start, and we work with a lot of small businesses in exactly this position. If you'd like a second pair of eyes on what you're running, I'm happy to talk it through.

Sources

Keep reading

← Back to Insights