Bloom Security says GitHub stopped replying to its validated bug bounty report on a serious npm publishing flaw for about three months, then fixed the issue without telling the researchers. The SlugFest case shows how a bounty programme can fail the people it depends on, even when the bug itself gets fixed.
What happened
On 6 June 2026, researchers at Bloom Security submitted a report through GitHub’s bug bounty programme on HackerOne. It described a weakness in npm Trusted Publishing, the feature that lets maintainers publish packages from automated workflows without keeping long-lived tokens. GitHub, which owns npm, triaged and validated the report on 9 June.
Then the conversation stopped. Bloom says the last reply came on 8 July, and six later enquiries, including a request for HackerOne to mediate, went unanswered. With no word on a fix or a disclosure date, the team prepared to go public, first sending its findings to npm and rerunning its proof of concept. It failed, because a fix was already live.
GitHub had announced the change in a changelog entry on 2 October, almost four months after the original report, without, as far as Bloom says, telling the researchers who found the problem. npm later confirmed the fix and apologised for the delayed communication. Bloom published its research, which it calls SlugFest, on 13 October. No bounty award or amount has been disclosed.
A GitHub spokesperson told Help Net Security the company validated the report and shipped fixes, but did not address the months of silence.
The technical picture
The bug explains why the silence matters. Trusted Publishing works by having a GitHub Actions workflow request a signed OpenID Connect token, which npm swaps for a publishing credential that lasts only minutes. The maintainer tells npm which repository and workflow file are allowed to publish.
According to Bloom, npm stored that repository as its human-readable name (the owner/repo “slug”) rather than the permanent numeric ID GitHub gives every repository and account. Both IDs were in the token, but npm did not check them. If a maintainer renamed, transferred or deleted the linked repository, or the owning account changed its name, the old slug could often be claimed by anyone, although GitHub retires some popular names. An attacker who registered it and added a workflow with the right filename could obtain publishing rights over someone else’s package. They would not need to steal any password or token.
Bloom tested the attack on a package and repositories it controlled, publishing from a second organisation’s repository. It says such a release still ships with a genuine provenance attestation, one that simply names the attacker’s repository. A registry-wide scan found more than 1,500 exposed packages, together downloaded over 10 million times, and CSO Online reports that one package alone gets over 200,000 downloads a month. Bloom has not seen any exploitation in the wild, and it says npm’s GitLab integration had the same weakness.
The fix makes Trusted Publishing configurations that have never been used expire 48 hours after creation. A configuration’s first successful publish now ties it to the repository’s permanent identity. npm also now rejects tokens from GitHub Actions issue_comment events. Bloom points out that PyPI’s Warehouse already checks repository IDs, so the safer design was known.
Why it matters for UK organisations
Many UK organisations that build software pull from npm, increasingly through AI coding agents that install dependencies unreviewed. Based on telemetry from dozens of organisations, Bloom estimates agents install about 70 packages per endpoint each month, rising to nearly 350 on developer machines. A hijacked package with an install script could run on any machine that pulls it in.
The disclosure lesson cuts closer to home, though. The UK’s voluntary Software Security Code of Practice, drawn up by DSIT with the NCSC, expects vendors to “implement and publish an effective vulnerability disclosure process” and to give customers timely updates and notifications. A process that accepts a report, confirms it and then goes quiet is not effective in any useful sense. UK firms that sell software into the EU now also face Cyber Resilience Act deadlines. Since 11 September, manufacturers must send ENISA an early warning within 24 hours of becoming aware of an actively exploited vulnerability. A triage queue where valid reports go unanswered for months is exactly where that awareness gets lost.
For UK researchers, with Computer Misuse Act reform still unfinished, a programme’s safe harbour is often their main legal protection. When a programme goes quiet, they must choose between waiting indefinitely and publishing without the vendor’s agreement.
Expert view
I have spent much of my career on both sides of disclosure. The pattern here is familiar and rarely malicious: a report is validated, passed to engineering, fixed, and nobody owns the conversation with the person who found it. The ticket closes and the researcher is still waiting.
That is still a failure. The whole point of a bounty programme is to trade a researcher’s patience and silence for engagement and, ideally, a reward. When the vendor stops engaging, the deal falls apart. A mediation request that goes unanswered is particularly worrying, because mediation is the platform’s safety valve. If that doesn’t work, researchers learn that the official route goes nowhere, and some of them will stop using it.
Bloom deserves credit for retesting before publishing, and GitHub for a sensible fix. But both happened despite the process, not because of it. In my experience, a short, regular status update costs almost nothing and avoids nearly every dispute of this kind.
With programmes handling more machine-generated reports, clear service levels for validated findings matter more than ever. A confirmed high-impact issue should never sit in the same queue as the noise.
What to do now
- Audit Trusted Publishing bindings. If you maintain npm packages, run npm trust list and check that every repository listed still resolves to one you control. Recreate bindings after any rename or transfer, and remove them before deleting a repository.
- Check provenance properly. Don’t just confirm an attestation exists. Check that it names the repository the package should come from.
- Control what gets installed. Limit what developers and AI agents can install, and review install scripts in your build systems. This fits Cyber Essentials secure configuration and the software side of malware protection.
- Fix your own disclosure process. Set response targets for validated reports, name an owner for each researcher conversation, and promise status updates at fixed intervals, in line with action 3.2 of the Software Security Code of Practice.
- Plan for escalation. If you use a bounty platform, agree how mediation requests are handled and who answers them. Test it the way you would test incident response.
- Tell researchers when you fix things. Let the reporter know before or when a fix ships, and coordinate the disclosure date.
Bottom line
SlugFest was a significant supply chain flaw, now fixed, but its finders had to retest it themselves to learn that. For UK organisations running or relying on bounty programmes, a programme is only as trustworthy as its follow-up: validate quickly, keep researchers informed, and make sure mediation requests reach someone.
Sources
- Help Net Security: npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover
- The Next Web: npm Trusted Publishing flaw left 1,500 packages open to attackers
- CSO Online: Over 1,500 npm packages exposed by Trusted Publishing validation flaw
- GitHub Changelog: Unvalidated npm trusted publishing configurations now expire
- GOV.UK (DSIT): Software Security Code of Practice
- HackerOne: EU CRA Reporting Goes Live This Friday. Are You Ready?
