Notre réponse à une attaque de la chaîne logicielle sur npm

Le 12 mai 2026, nous avons évalué notre exposition à la campagne Mini Shai-Hulud, une attaque de la chaîne logicielle alors en cours, après la publication de rapports décrivant des paquets compromis dans les écosystèmes npm et PyPI. Parmi eux figuraient des paquets TanStack et intercom-client.

Nous n’avons trouvé aucun élément indiquant que les systèmes de production de Transloadit, les données des clients ou les paquets que nous avons publiés aient été touchés. Nous avons toutefois profité de cet incident pour renforcer les protections des installations de dépendances et des circuits de publication de versions via GitHub Actions dans nos dépôts.

Ce qui s’est passé

En bref, les attaquants ne s’appuient plus uniquement sur des jetons volés de gestionnaires de paquets ou sur des noms de paquets imitant des noms légitimes. Dans l’incident TanStack, le rapport rétrospectif⁠ des responsables de maintenance décrit une chaîne combinant un flux de travail pull_request_target, l’empoisonnement du cache GitHub Actions et l’accès aux jetons de publication de confiance/OIDC. Des paquets malveillants ont ainsi pu être publiés par l’intermédiaire de l’infrastructure officielle de publication de versions.

Le suivi de Mini Shai-Hulud⁠ de Socket relie également la campagne à des paquets compromis, tels que intercom-client@7.0.4 sur npm et lightning 2.6.2/2.6.3 sur PyPI. Les charges utiles signalées ciblent les environnements de développement et de CI, à la recherche d’informations d’accès telles que des jetons GitHub, des jetons npm, des clés cloud, des clés SSH et la configuration des outils d’IA.

C’est important, car les systèmes de CI sont souvent proches du code source, des informations d’accès au déploiement, des autorisations de publication de paquets et de l’infrastructure cloud. L’installation d’une dépendance malveillante au mauvais endroit peut devenir bien plus qu’un problème de développement local.

Impact sur Transloadit

Nous n’avons trouvé aucun indice d’impact sur les services de Transloadit ou les données des clients.

Notre examen comprenait les points suivants :

• Vérifier les dépôts utilisant intercom-client. Nous en avons trouvé dans le dépôt Website, l’API et d’autres dépôts internes. Toutefois, dans chacun de ces cas, la version était fixée et la résolution aboutissait à intercom-client@5.0.0, et non aux versions malveillantes signalées 7.0.4 ou 7.0.5.
• Rechercher les fichiers suspects et les indicateurs connus de la campagne, notamment router_init.js, router_runtime.js, execution.js, les fichiers suspects de flux de travail shai-hulud et la référence git malveillante signalée pour TanStack.
• Rechercher le mécanisme de persistance signalé, qui surveille les jetons GitHub, sur les machines de développement utilisées dans le cadre de cet examen.
• Examiner nos flux de travail GitHub Actions pour rechercher le schéma risqué précis mis en évidence par le rapport rétrospectif de TanStack : du code de pull request non fiable accédant à un cache de confiance ou à un flux de travail de publication de versions de confiance.

Les versions affectées que nous avons recherchées n’étaient présentes ni dans les fichiers de verrouillage examinés ni dans les copies installées examinées. Nous n’avons pas non plus trouvé les indicateurs connus de persistance ou de charge utile dans les arbres de travail examinés.

Ce que nous avons changé

Nous avons ouvert et mis à jour plusieurs pull requests de renforcement de la sécurité dans nos dépôts. Ces changements sont volontairement limités : ils réduisent l’exposition aux attaques de la chaîne logicielle sans modifier le comportement du produit.

Voici les principaux changements :

• Délai minimal depuis la publication des dépendances. Dans les dépôts Yarn qui n’en avaient pas déjà un, nous avons ajouté npmMinimalAgeGate: 2880, qui empêche l’installation des versions de paquets nouvellement publiées pendant 48 heures. Cela laisse à l’écosystème le temps de détecter et de supprimer de nombreuses versions compromises avant qu’elles puissent entrer dans nos compilations.
• Installations immuables. Nous avons modifié les installations de CI admissibles pour utiliser un fonctionnement immuable ou un fichier de verrouillage figé, afin que la CI ne résolve pas de nouvelles versions de dépendances au gré de leur disponibilité.
• Frontières des caches de publication de versions. Nous avons supprimé la restauration du cache partagé des dépendances dans les circuits de publication de versions ou de paquets où elle pouvait franchir des frontières de confiance. Nous avons notamment mis à jour les circuits de publication de versions ou de téléversement vers le CDN dans monolib, locutus et uppy.
• Examen de la CI des dépôts publics. Nous avons recherché pull_request_target et les flux de travail ayant accès à des secrets dans les dépôts publics. Lorsque des dépôts publics ont besoin de secrets pour la CI, nous privilégions une approbation protégée par un environnement et liée au code précis testé, plutôt qu’une procédure « test autorisé » reposant uniquement sur une étiquette.
• Historique Git vérifié, avec ajouts uniquement. Nous avons activé à l’échelle de l’organisation des règles GitHub qui exigent des commits vérifiés et bloquent les poussées forcées dans les dépôts Transloadit. Une enquête complémentaire a renforcé la conclusion selon laquelle les branches autres que celles par défaut et les références obsolètes font partie de la surface d’attaque : si un attaquant peut réécrire une branche partagée avec des métadonnées d’auteur falsifiées, l’historique malveillant peut paraître plus familier qu’il ne l’est réellement.

Pourquoi ces mesures sont utiles

Aucun réglage ne prévient à lui seul toutes les attaques de la chaîne logicielle. L’objectif est d’ajouter plusieurs couches d’obstacles :

• Un délai minimal depuis la publication des paquets réduit le risque d’installer une version fraîchement compromise pendant les premières heures d’une attaque.
• Les installations immuables permettent à la CI et aux déploiements de reproduire le fichier de verrouillage examiné au lieu de découvrir de nouvelles versions pendant l’exécution.
• Éviter les caches partagés dans les circuits de publication de versions réduit le risque que des tâches non fiables ou de moindre confiance laissent des artefacts qu’une tâche ultérieure de publication de confiance restaurera.
• Des autorisations GitHub Actions explicites et des approbations d’environnement empêchent les tâches ayant accès à des secrets de s’exécuter sur du code de fork non examiné.
• Les commits vérifiés compliquent l’usurpation d’identité, et le blocage des mises à jour sans avance rapide préserve l’historique des branches partagées pour qu’il reste examinable.

L’incident TanStack a utilement rappelé que les caches de compilation et les tâches de publication de versions font partie du périmètre de sécurité. Nous les traitons désormais comme tels de manière plus cohérente.

Ce que les clients doivent faire

À l’issue de cet examen, aucune action propre à Transloadit n’est requise de la part des clients.

Si vous avez installé des paquets publiquement répertoriés comme affectés par Mini Shai-Hulud le 29 avril 2026 ou après cette date, nous vous recommandons de suivre les consignes des responsables de maintenance des paquets concernés. En général, cela implique de vérifier les fichiers de verrouillage et les journaux de CI, de supprimer les versions affectées et de renouveler toutes les informations d’accès qui étaient accessibles depuis les environnements dans lesquels les paquets malveillants ont pu s’exécuter.

Pour vos propres systèmes de CI, nous recommandons les mêmes mesures que celles que nous appliquons :

• Utiliser uniquement le fichier de verrouillage pour les installations dans les flux de travail de CI et de déploiement.
• Ajouter un délai minimal depuis la publication des dépendances lorsque votre gestionnaire de paquets le permet.
• Éviter les caches de dépendances dans les flux de travail de publication ou de déploiement.
• Faire preuve d’une grande prudence avec pull_request_target ; ne pas l’associer à la fois à l’extraction de code de pull request non fiable et à l’accès à des secrets ou à des jetons autorisant l’écriture.
• Limiter autant que possible les autorisations GitHub Actions et ne les augmenter que dans la tâche qui en a besoin.
• Désactiver les poussées forcées sur les branches partagées des dépôts lorsque c’est possible. Si les développeurs doivent retravailler l’historique, privilégiez de nouvelles branches plutôt que de réécrire celles que d’autres personnes ou des automatisations peuvent récupérer.

Conclusion

Nous remercions les responsables de maintenance et les chercheurs qui ont rapidement publié des détails techniques et des indicateurs. Cela a permis à des équipes comme la nôtre de vérifier rapidement leur exposition et de transformer les enseignements tirés en mesures concrètes de renforcement de la sécurité.

Nous continuerons à surveiller la campagne et mettrons cet article à jour si nous découvrons un impact significatif sur Transloadit ou une action requise de la part des clients.