TanStack npm : 84 versions piégées via un trusted-publisher OIDC

Le contexte

Cette CVE est le premier maillon de la campagne baptisée Mini Shai-Hulud, attribuée au groupe TeamPCP, ajoutée au KEV de la CISA le 27 mai aux côtés de CVE-2026-48027 (Nx Console) et CVE-2026-8398 (DAEMON Tools Lite). Les trois illustrent trois vecteurs distincts d'attaque sur la supply chain et se chaînent entre elles.

Le 11 mai, entre ~19h20 et 19h26 UTC, des attaquants ont publié 84 versions malveillantes réparties sur 42 paquets @tanstack/* (deux versions piégées par paquet, publiées à quelques minutes d'intervalle).

La mécanique

Le mode opératoire est instructif (CWE-506, code malveillant embarqué) : les attaquants ont abusé du binding trusted-publisher OIDC de GitHub Actions associé au dépôt TanStack/router.

Concrètement, une mauvaise configuration de pull_request_target, combinée à un empoisonnement de cache et au vol du jeton OIDC depuis la mémoire du runner, leur a permis de publier sous l'identité npm légitime de TanStack. Les artefacts portaient donc une signature de confiance alors qu'ils provenaient de code contrôlé par l'attaquant. Le payload était un voleur d'identifiants.

Remédiation

Une simple disparition de la version piégée d'un lockfile ne suffit pas. Il faut :

1. une analyse de composition logicielle (SCA) complète pour identifier tous les composants embarquant les versions affectées ;
2. purger les caches d'artefacts (npm, CI, miroirs internes) ;
3. reconstruire les builds en aval ;
4. présumer toute machine ayant résolu ces versions comme potentiellement compromise (rotation des secrets atteignables).

Ce qu'il faut retenir

L'identité trusted-publisher npm est un canal de confiance : compromise, elle signe du code malveillant qui passe tous les contrôles de réputation. La détection ne peut pas reposer sur la signature ou la provenance - seule une SCA exhaustive sur la fenêtre du 11 mai, suivie d'une purge de caches et d'une rotation de secrets, ferme réellement l'incident.

• Kreomnis