npm : le nom du dépôt valait clé de publication

Ce qui se passe

Bloom Security a publié « SlugFest », un défaut de la publication de confiance (trusted publishing) de npm. Tant qu'aucune version n'avait été publiée depuis un dépôt GitHub, le registre retenait son adresse (propriétaire/dépôt, le slug) et non son identifiant numérique permanent. Qui récupérait une adresse libérée pouvait publier sous le nom du paquet, sans voler le moindre identifiant.

GitHub a répondu le 2 octobre : une configuration de publication de confiance jamais validée expire 48 heures après sa création.

Le mécanisme

La publication de confiance remplace le jeton npm durable par un jeton OIDC de quelques minutes, émis par le workflow GitHub Actions. Quand on lie un paquet à un dépôt, la CLI n'envoie que trois champs : repository (le texte propriétaire/dépôt), workflow_ref.file (le nom du fichier de workflow) et environment (facultatif). Les identifiants repository_id et repository_owner_id, présents dans chaque jeton OIDC, ne sont enregistrés qu'après la première publication réussie.

Conditions de l'attaque : le dépôt lié a été renommé, transféré ou supprimé (ou son propriétaire renommé ou supprimé), et il n'a jamais servi à publier.

L'attaque en trois échanges : npm compare l'adresse, jamais l'identifiant numérique

Ce que ça permet

publier une version piégée sous le vrai nom, avec la réputation, les téléchargements et les dépendants du paquet ;
produire une attestation de provenance Sigstore valide, signée par le dépôt de l'attaquant : un outil qui se contente de vérifier « signé » ne voit rien, il faut comparer le dépôt attesté au dépôt attendu ;
atteindre les agents de code, qui installent seuls la dernière version : Bloom compte environ 70 paquets installés par mois et par poste, près de 350 sur une machine de développeur.

Un scan du registre a trouvé plus de 1 500 paquets vulnérables, plus de 10 millions de téléchargements cumulés (plus d'un million par mois). La liste n'est pas publiée.

Le correctif et son calendrier

6 juin : signalement par HackerOne ; 9 juin : validé ; 8 juillet : dernière réponse de GitHub ; 2 octobre : correctif, soit plus de 120 jours.
Une configuration non validée expire après 48 heures ; la première publication réussie la valide et la lie à l'identité permanente du dépôt. Changer de dépôt ou de projet ouvre une nouvelle fenêtre de 48 heures ; les modifications ordinaires ne la relancent pas.
npm rejette aussi les jetons issus des événements issue_comment de GitHub Actions, en plus de la restriction existante sur pull_request_target.

Limite : le correctif borne la fenêtre, il ne lie pas l'identifiant dès la création. PyPI le fait depuis son lancement ; l'implémentation GitLab de npm était touchée aussi. Les sources ne disent pas ce qu'il advient des liaisons anciennes jamais utilisées.

Comment s'y prendre

Lister les liaisons de chaque paquet et vérifier que l'adresse désigne toujours un dépôt que vous contrôlez :
Terminal
```
npm trust list
```
Dépôt renommé ou transféré : supprimer la liaison, la recréer avec l'adresse courante.
Avant de supprimer, renommer ou transférer un dépôt lié : retirer d'abord la liaison.
Après la création d'une liaison, publier une version tout de suite pour la valider.
Surveiller les publications que vous n'avez pas lancées depuis le dépôt attendu.

Sources : SlugFest, Bloom Security ; Unvalidated npm trusted publishing configurations now expire, GitHub, 2 octobre 2026 ; relayé par The Hacker News le 13 octobre 2026.