Attaque TanStack : Comment la provenance SLSA a été utilisée comme arme contre la chaîne de confiance CI/CD

L’attaque qui a brisé une garantie de sécurité

La sécurité de la chaîne d’approvisionnement logicielle repose sur une hypothèse fondamentale : si un package porte une provenance valide, il a été construit à partir d’un code source de confiance par un système CI/CD de confiance. L’attaque TanStack de mai 2026 a brisé cette hypothèse.

Selon l’analyse post-mortem détaillée de Rescana, le groupe TeamPCP n’a pas falsifié la provenance, contourné une clé de signature ou exploité une vulnérabilité dans la spécification SLSA elle-même. Ils ont fait quelque chose de plus insidieux : ils ont détourné le runner CI/CD légitime via l’extraction de token OIDC depuis la mémoire du processus, puis ont utilisé l’identité propre de ce runner pour publier des packages malveillants. Les packages étaient, par toute mesure vérifiable, construits depuis l’infrastructure GitHub en utilisant les propres identifiants du projet. La provenance SLSA était exacte — et inutile.

L’attaque s’est déroulée sur 20 à 26 minutes le soir du 11 mai 2026 UTC. Dans cette fenêtre, 84 versions malveillantes de 42 packages @tanstack ont été publiées. En quelques heures, le payload auto-réplicant s’était propagé à plus de 200 packages supplémentaires, dont des composants @mistralai et @uipath. Le 12 mai, npm avait supprimé les archives malveillantes — mais l’incident avait déjà exposé l’écart critique entre ce que SLSA garantit et ce que les développeurs supposent qu’il garantit.

Ce que TeamPCP a réellement fait

La chaîne d’attaque comporte quatre phases que tout ingénieur CI/CD devrait comprendre.

Phase 1 — Empoisonnement du cache : Un fork contrôlé par l’attaquant a introduit des binaires malveillants dans le cache GitHub Actions. Ces binaires n’ont pas été détectés comme malveillants car le cache n’est pas soumis au même scanning que le code source commité.

Phase 2 — Extraction du token OIDC : Lors d’une exécution de workflow standard qui restaurait le cache empoisonné, les binaires malveillants ont extrait des tokens OpenID Connect directement depuis la mémoire du processus du runner. Les tokens OIDC sont des identifiants porteur à courte durée de vie que GitHub Actions utilise pour s’authentifier auprès de services externes — dont npm. Aucun secret de longue durée n’était nécessaire ; le runner lui-même était l’identifiant.

Phase 3 — Publication malveillante : Utilisant le token OIDC volé, TeamPCP a publié 84 versions de packages sur npm sous l’espace de noms @tanstack. Parce que le token était légitime et que les packages étaient publiés depuis les plages IP de GitHub, la détection de fraude de npm n’a pas été déclenchée.

Phase 4 — Exécution du payload : Chaque version malveillante contenait un fichier JavaScript obfusqué de 2,3 Mo nommé router_init.js qui récoltait des identifiants AWS, des tokens GCP, des tokens GitHub, des clés SSH et des tokens Kubernetes depuis l’environnement du développeur et les exfiltrait via le réseau de messagerie décentralisé Session/Oxen. Un daemon de persistance destructif nommé gh-token-monitor effaçait le répertoire personnel de l’utilisateur si les tokens GitHub étaient ultérieurement révoqués.

Le bulletin d’alerte cyber CC-4781 de NHS Digital a confirmé la portée multi-écosystème de l’attaque et son impact sur les outils du secteur de la santé, soulignant que les bibliothèques de routeur TanStack sont embarquées bien au-delà des équipes JavaScript natives.

Ce que les équipes d’ingénierie doivent faire

1. Traiter la provenance SLSA comme nécessaire mais insuffisante

L’incident TanStack recadre la provenance SLSA d’un signal de confiance en signal de traçabilité. La provenance vous dit où un package a été construit ; elle ne vous dit pas si l’environnement de build était propre à ce moment-là. Les organisations qui ont supprimé les packages non attestés de leurs listes d’autorisation après 2024 doivent maintenant ajouter une deuxième couche : analyse comportementale d’exécution et scanning post-installation. Des outils tels que la surveillance de la chaîne d’approvisionnement de Socket.dev ou la revue de dépendances de GitHub Advanced Security signalent des anomalies comportementales — appels réseau au moment de l’installation, spawn de processus, modèles d’accès aux chemins de credentials — que la provenance ne peut pas détecter.

2. Isoler les runners GitHub Actions des stores de credentials

L’extraction du token OIDC dans l’attaque TanStack nécessitait que le binaire malveillant s’exécute en processus sur le runner Actions. Les organisations peuvent limiter le rayon de l’explosion en s’assurant que les runners CI/CD n’ont pas d’accès direct aux stores de credentials de production, aux rôles IAM cloud avec permissions d’écriture, ou aux tokens de publication npm avec une portée large. Utilisez des tokens OIDC à courte durée de vie et portée avec des restrictions d’audience explicites, et faites tourner les credentials de publication après chaque cycle de release. Les tokens npm de publication à granularité fine de GitHub — qui limitent la publication à des packages spécifiques et des contextes d’automatisation — ont été spécifiquement conçus pour ce modèle de menace.

3. Auditer chaque entrée du cache GitHub Actions ce sprint

Le point d’entrée de l’attaque était une entrée de cache empoisonnée. Lancez un audit immédiat : listez toutes les clés de cache actives (gh cache list), vérifiez le workflow qui a créé chaque entrée, et supprimez toutes les entrées de cache qui ne peuvent pas être attribuées à une exécution de workflow connue et propre. À l’avenir, ancrez les clés de cache à des hachages de commit SHA plutôt qu’à des noms de branches, et activez le paramètre « Ne pas sauvegarder le cache pour les workflows échoués ».

4. Épingler les dépendances à des hachages de digest vérifiés, pas à des plages de versions

Les plages de versions de packages (^1.2.0, ~2.3) sont le mécanisme qui a permis aux packages malveillants TanStack d’être automatiquement récupérés par des projets qui faisaient déjà confiance à l’espace de noms @tanstack. Épinglez chaque dépendance directe et transitive à un hachage de digest immuable dans votre fichier de verrouillage, et vérifiez que votre pipeline CI/CD échoue si le fichier de verrouillage a changé sans revue de code correspondante.

5. S’abonner aux flux de sécurité de l’écosystème et automatiser la réponse

L’incident TanStack a été détecté par un chercheur externe en 20 à 26 minutes — plus rapidement que les alertes de sécurité internes de la plupart des organisations. Les organisations utilisant des packages @tanstack auraient eu un signal exploitable dans l’heure si elles s’étaient abonnées aux avis de sécurité npm, aux GitHub Security Advisories, ou aux flux tiers comme OSV.dev. Automatisez la réponse : configurez votre pipeline de gestion des dépendances pour bloquer automatiquement les builds lorsqu’un package apparaît sur l’un de ces flux, sans attendre qu’un humain trie l’alerte.

La leçon structurelle : Les chaînes de confiance sont aussi solides que leur hypothèse la plus faible

L’attaque TanStack est une démonstration précise d’un risque de chaîne d’approvisionnement de second ordre : les adversaires qui ne peuvent pas briser vos contrôles cryptographiques vont plutôt compromettre le contexte dans lequel ces contrôles sont exercés. La provenance SLSA est cryptographiquement solide. Les tokens OIDC sont cryptographiquement solides. La mémoire du processus du runner ne l’est pas.

La surveillance continue des attaques de la chaîne d’approvisionnement npm par l’Unit 42 documente une tendance claire : la sophistication des attaques augmente plus rapidement que l’adoption des contrôles défensifs. La réponse industrielle à l’attaque SolarWinds de 2020 était d’exiger des SBOM et une provenance de build. L’attaque TanStack démontre que les attaquants se sont déjà adaptés.

L’implication pratique est inconfortable : il n’existe pas de contrôle unique qui rende un pipeline CI/CD digne de confiance. La défense nécessite une superposition — attestation de provenance, surveillance comportementale d’exécution, épinglage des dépendances, isolation des runners et alertes rapides de l’écosystème — aucune n’étant suffisante seule. L’incident de mai 2026 devrait réinitialiser cette hypothèse de façon permanente.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Attaque sur la chaîne d’approvisionnement npm TanStack — Analyse détaillée — Rescana
• Surveillance des attaques sur la chaîne d’approvisionnement npm — Unit 42, Palo Alto Networks
• Renforcer la sécurité de la chaîne d’approvisionnement — GitHub Blog
• Alerte cyber CC-4781 : Compromission de la chaîne d’approvisionnement TanStack — NHS Digital
• Instructure conclut un accord de rançon — The Hacker News