Contexte technique
Je me suis penché sur le post-mortem de TanStack dès sa publication car ce n'est pas juste un autre incident npm. C'est pire : les paquets malveillants ont été publiés via le pipeline de release officiel, ce qui signifie que toute équipe développant des intégrations d'IA ou des environnements de production basés sur la confiance en la provenance devrait s'inquiéter.
La fenêtre d'attaque a été brève : le 11 mai 2026, de 19:20 à 19:26 UTC. En l'espace de six minutes, un attaquant a publié 84 versions malveillantes sur 42 paquets @tanstack/*.
Les mots de passe des mainteneurs n'ont pas été volés. Le workflow `npm publish` n'a pas non plus été directement piraté. L'attaquant a manipulé les entrées du CI de telle sorte que le propre pipeline de TanStack a publié les builds infectés en utilisant son identité OIDC de confiance.
Et c'est là que j'ai vraiment dû marquer une pause : les releases avaient des attestations de provenance valides. Cela signifie que la logique habituelle de "s'il y a une signature et une publication de confiance, alors c'est sûr" a complètement échoué dans ce cas.
La chaîne d'attaque était très moderne. D'abord, ils ont exploité le dangereux pattern `pull_request_target`, la fameuse Pwn Request. Ensuite, ils ont empoisonné le cache de GitHub Actions à la frontière entre le fork et le dépôt de base. Finalement, dans la tâche de release, ils ont extrait le jeton OIDC à courte durée de vie directement de la mémoire du processus du runner.
Essentiellement, le CI s'est volé le jeton à lui-même au moment de la publication. Il ne s'agit plus de "ne stockez pas de secrets dans le repo". Il s'agit de considérer que les caches, les artefacts et les frontières de confiance (trust boundaries) dans GitHub Actions doivent être considérés comme hostiles par défaut.
Si vous avez récupéré @tanstack/* pendant cette période, je ne me contenterais pas de mettre à jour la version. Je reconstruirais le projet avec un `lockfile` propre, viderais le cache, vérifierais les logs du CI à la recherche de requêtes réseau étranges et changerais tous les secrets si le paquet infecté a été exécuté dans le pipeline.
Ce que cela change pour les entreprises et l'automatisation
Les équipes dont les releases reposent sur "on a la publication de confiance" sont les perdantes ici. Les gagnants sont ceux qui séparent les PR non fiables, les builds et les publications dans différentes zones de confiance.
La deuxième conclusion est encore plus pratique : la sécurité de la chaîne d'approvisionnement ne peut plus être gérée manuellement avec une checklist trimestrielle. Il faut des politiques robustes, une analyse du `lockfile`, un contrôle du cache, une réponse aux incidents et des restaurations automatisées.
Chez Nahornyi AI Lab, nous traitons précisément ces problèmes : nous concevons une architecture de solutions d'IA autour des processus DevSecOps afin que les équipes ne découvrent pas une compromission après coup dans les logs. Si votre CI/CD est devenu complexe et que personne ne peut prouver rapidement ce qui est sécurisé, analysons-le et construisons une automatisation par IA adaptée à votre workflow réel, et non pour un joli schéma dans Notion.