Comment l'attaque NPM voleur de secrets fonctionne-t-elle ?
Le Registre NPM est au cœur de l’écosystème JavaScript, fournissant des millions de paquets qui facilitent le développement d’applications modernes. Mais derrière cette immense bibliothèque de ressources se cachent aussi des risques importants pour la sécurité des projets. Parmi eux, l'attaque du « voleur de secrets » sur NPM a récemment attiré l’attention des développeurs et des entreprises, démontrant comment des acteurs malveillants peuvent exploiter des paquets pour voler des informations sensibles.
Dans cet article, nous allons explorer en détail cette menace, comprendre son fonctionnement et découvrir les meilleures pratiques pour protéger vos projets contre ce type d’attaque.
Comment l’attaque registre NPM s’est-elle déroulée
L’attaque a commencé le 14 septembre 2025 enciblant directement le registre NPM. Les assaillants ont pris le contrôle de plusieurs comptes de développeurs en utilisant des identifiants compromis, selon les rapports, puis ont utilisé ces comptes pour publier des mises à jour malveillantes.
La première vague de diffusion est restée limitée, mais le code malveillant s’est comporté comme un ver : en l’espace de quelques jours, la campagne avait infecté de nombreux packages gérés par différents mainteneurs.
En utilisant les identifiants volés, les attaquants ont automatisé le reconditionnement et la republication de modules infectés. Rapidement, de nombreuses versions malveillantes ont été publiées sur le registre NPM.
Certains des packages compromis étaient des bibliothèques largement utilisées, comme @ctrl/tinycolor ou ngx-bootstrap.
L’attaque a même brièvement touché des packages maintenus par des entreprises de cybersécurité reconnues avant leur retrait, illustrant la rapidité et l’ampleur avec lesquelles une compromission de ce type peut se propager dans la chaîne d’approvisionnement logicielle.
Méthode de fonctionnement de l’attaque sur le registre NPM
Le code malveillant est intégré dans un script post-installation. Lorsqu’un développeur exécute npm install sur un package compromis, ce script s’active automatiquement, déclenchant l’ensemble une séquence d’attaque.
Étape 1 : Exécution et ciblage
La première action du script consiste à vérifier le système d’exploitation de la machine victime. Il ignore délibérément les environnements Windows et cible uniquement Linux et macOS. Cette étape permet aux attaquants de concentrer leurs efforts sur les systèmes les plus exposés.
Étape 2 : Vol des secrets
La fonction principale du script est la collecte des secrets.
Il télécharge TruffleHog, un outil open-source de recherche de secrets.
Il l’utilise pour scanner systématiquement le système infecté à la recherche de clés et jetons (tokens) d’API.
Il récolte également les variables d’environnement, les clés cloud exposées via les services IMDS, et toute autre information sensible disponible.
Les attaquants ont fait évoluer ce script : certaines versions visaient spécifiquement les identifiants Azure, tandis que d’autres rendaient le processus d’exfiltration plus discret.
Étape 3 : Exfiltration audacieuse
Le script exfiltre les informations de manière à maximiser leur impact.
Si un jeton GitHub est trouvé, il est utilisé pour créer un nouveau dépôt public sous le compte de la victime, dans lequel toutes les données volées sont téléchargées.
Le script peut également injecter un workflow GitHub Actions dans les dépôts de la victime, conçu pour exfiltrer en continu de nouveaux secrets vers un serveur contrôlé par les attaquants.
Étape 4 : Auto-propagation via le registre NPM
La caractéristique la plus dangereuse du script est sa capacité à se propager automatiquement dans le registre NPM.
Si un jeton NPM valide est détecté, le script prend le contrôle de tous les packages auxquels le mainteneur compromis a accès.
Il publie automatiquement de nouvelles versions infectées de ces packages.
Chaque nouveau package infecté devient à son tour un vecteur de propagation : quiconque l' installe verra son système analysé et ses propres packages potentiellement compromis.
Ce mécanisme crée une réaction en chaîne auto-entretenue à travers la chaîne d’approvisionnement logicielle.
Publication des données volées
Les informations récoltées par le script malveillant étaient exfiltrées de deux méthodes complémentaires, garantissant ainsi leur accessibilité pour les attaquants.
La première méthode consistait à utiliser les dépôts GitHub de la victime. Après avoir obtenu son jeton d'accès, le script créait un nouveau dépôt public en son nom et y téléversait un fichier contenant l'intégralité des données collectées, incluant les secrets et les métadonnées système.Cette approche permettait aux attaquants de centraliser rapidement les informations volées dans un espace accessible en ligne.
La seconde méthode exploitait les workflows GitHub Actions de la victime. Le script générait un nouveau workflow qui codait automatiquement les secrets collectés dans un format JSON et les envoyait vers un serveur externe contrôlé par les attaquants. Cette technique assurait une exfiltration persistante et discrète, même après la création initiale du dépôt.
Grâce à ces deux canaux, les attaquants pouvaient récupérer efficacement les informations sensibles tout en restant discrets, ce qui amplifiait considérablement l’impact de l’attaque sur le registre NPM et sur la chaîne d’approvisionnement logicielle associée.
Gestion de l'incident
L’infection du paquet tinycolor et d’une vingtaine d’autres a été détectée durant la nuit du 15 au 16 septembre ; dès le matin, l’équipe du registre NPM a commencé à restaurer les versions saines des packages compromis. Si les versions malveillantes ont pu être supprimées de l'historique public du registre, des preuves de leur existence restent consultables via les annonces de sécurité et les dépôts GitHub dédiés. Même si l’activité semblait stabilisée au moment des premiers rapports, le caractère auto-réplicatif de l’attaque oblige à maintenir un haut niveau de vigilance tant que la publication de fichiers malveillants n’est pas bloquée définitivement.
Comment se défendre contre ce type de menaces
Mesures recommandées pour les équipes affectées et la communauté :
Restauration et nettoyage immédiats : Revenir aux versions saines des paquets et vider le cache npm pour éliminer toute trace des composants malveillants.
Audit des environnements : Vérifier les pipelines CI/CD et postes développeurs pour identifier des modifications non autorisées (workflows injectés, scripts ajoutés).
Analyse des logs : Contrôler les journaux d’accès et de publication NPM pour repérer des activités suspectes.
Révocation et rotation des secrets : Révoquer immédiatement tous les jetons et clés potentiellement exposés (npm, GitHub, AWS, GCP, Azure).
Blocage préventif : Collaborer avec l’équipe du registre NPM pour empêcher la republication de fichiers malveillants.
Communication transparente : Informer rapidement les utilisateurs et les équipes internes, en fournissant des instructions claires pour la procédure de retour arrière (rollback).
Renforcement post-incident : Imposer l'authentification à deux facteurs (MFA/2FA), limiter les privilèges des tokens, et intégrer des scans automatisés dans les workflows.
Surveillance continue : Maintenir une veille active sur les dépôts publics et les nouvelles publications afin de détecter toute récidive.
Conclusion
L’attaque contre le registre NPM a mis en lumière la vulnérabilité critique de la chaîne d’approvisionnement logicielle. En quelques heures seulement, des packages populaires ont été compromis, exposant les développeurs et les entreprises à un risque massif de fuite de données et de compromission de leurs environnements. Cet incident rappelle une évidence : la confiance aveugle dans les dépendances open source peut se transformer en point faible critique.
Pour la communauté, la leçon est double. D’une part, la prévention doit devenir un réflexe : gestion stricte des secrets, MFA, jetons à privilèges limités et scans automatisés. D’autre part, la détection et la réponse rapide sont essentielles pour contenir les effets d’une attaque et éviter sa propagation.
Au-delà du cas du registre NPM, cet incident appelle à un renforcement global de la chaîne de confiance dans l’écosystème open source . La sécurité ne peut plus être une réflexion après-coup ; elle doit en être l'un des piliers fondamentaux, intégrée dès la conception des projets.