SlugFest: npm Trusted Publishing lot angripere kapre over 1500 pakker via ledige reponavn

«Et navn er ikke en identitet», skriver Golan Myers i Bloom Security, som fant at npm Trusted Publishing stolte på navnet til GitHub-repoet i stedet for den permanente ID-en. Bloom fant over 1500 sårbare pakker med til sammen mer enn 10 millioner nedlastinger, over én million i måneden.

Trusted Publishing bytter et kortlivet OIDC-token fra GitHub Actions mot en publiseringsnøkkel hos npm, så du slipper langlivede tokens i CI. Men fram til første vellykkede publisering lagret npm bare owner/repo-strengen og filnavnet til workflowen, ikke repository_id og repository_owner_id. Ble repoet omdøpt, flyttet eller slettet før bindingen var brukt, ble navnet ledig. En angriper kunne da opprette et repo med samme navn, legge inn en workflow med samme filnavn, for eksempel release.yml, og få en gyldig publiseringsnøkkel uten å røre vedlikeholderens nøkler. Publiseringen fikk til og med en gyldig Sigstore-attestasjon, bare mot angriperens repo.

Bloom målte at et typisk endepunkt får rundt 70 pakker i måneden installert av agenter som Claude Code, Codex og Cursor, og nær 350 på utviklermaskiner. Hver av dem kan kjøre et postinstall-skript uten at noen ser på det.

Bloom meldte feilen via GitHubs HackerOne-program 6. juni 2026, og den ble bekreftet 9. juni. Ifølge GitHubs changelog utløper uvaliderte konfigurasjoner nå etter 48 timer, og npm avviser tokens fra issue_comment-hendelser i tillegg til pull_request_target. Endringen kom 2. oktober. Bloom skriver at hullet også fantes i GitLab-implementasjonen, og publiserer ikke lista over berørte pakker.

Hva bør du gjøre?

1. Kjør npm trust list for hver pakke du vedlikeholder, og sjekk at hvert reponavn fortsatt peker på et repo du kontrollerer.
2. Publiser en versjon rett etter at du oppretter en ny binding, og slett bindingen før du omdøper, flytter eller sletter repoet.
3. Flytt publisering til push, release eller workflow_dispatch hvis den i dag trigges av issue_comment.
4. Lås versjonene agentene dine installerer, og sjekk at provenance-attestasjonen peker på repoet du forventer, ikke bare at pakken er signert.