Publication de versions malveillantes de node-ipc sur npm à la suite d’une compromission présumée du compte d’un mainteneur

Le 14 mai 2026, plusieurs versions malveillantes du célèbre package npm node-ipc ont été publiées sur le registre npm. Les informations publiques disponibles identifient node-ipc@9.1.6, node-ipc@9.2.3 et node-ipc@12.0.1 comme des versions compromises contenant une charge utile obfusquée conçue pour voler des identifiants. Le code malveillant a été ajouté au bundle CommonJS, node-ipc.cjs, et s’exécute lorsque le package est chargé via require("node-ipc"). Les premières analyses suggèrent que l’attaque pourrait avoir exploité le compte légitime d’un mainteneur npm plutôt que compromis le pipeline CI/CD du projet. Les organisations ayant installé ces versions ou effectué des builds à partir de celles-ci doivent considérer comme potentiellement compromis les identifiants de développeurs, de CI/CD, de cloud, SSH, GitHub, Kubernetes et autres secrets accessibles depuis ces environnements. Snyk a publié un avis de sécurité concernant cet incident sous la référence SNYK-JS-NODEIPC-16697063. Les équipes doivent s’en servir pour identifier les dépendances vulnérables et prioriser les mesures correctives.

Composant concerné

node-ipc est un package Node.js utilisé pour la communication interprocessus. Il a longtemps été largement utilisé dans l’écosystème npm, directement ou comme dépendance transitive.

Ce n’est pas la première fois que node-ipc est associé à un incident de chaîne d’approvisionnement. En 2022, Snyk a analysé l’incident impliquant node-ipc et peacenotwar, au cours duquel un comportement de type protestware a touché des utilisateurs en aval. L’activité de mai 2026 semble être distincte. L’analyse actuelle ne pointe pas vers du protestware, mais vers des versions malveillantes contenant une charge utile obfusquée conçue pour voler des identifiants.

L’incident de 2026 semble distinct de celui de 2022. La charge utile de 2026 dont il est actuellement fait état vise le vol d’identifiants et leur exfiltration furtive, contrairement au comportement de type protestware observé en 2022. Les analyses publiques indiquent que la charge utile a été injectée dans le point d’entrée CommonJS et ne dépendait pas de scripts du cycle de vie npm tels que postinstall.

Versions connues comme affectées

Les informations publiques disponibles identifient ces trois versions malveillantes et indiquent qu’elles ont toutes été publiées le 14 mai 2026. Selon les rapports, le fichier node-ipc.cjs compromis était identique dans toutes les versions concernées.

Chronologie

Comment la compromission aurait eu lieu

L’hypothèse publique la plus solide est que les versions malveillantes ont été publiées par l’intermédiaire du compte npm d’un mainteneur disposant de droits de publication légitimes. StepSecurity a indiqué que les versions avaient été publiées par le compte atiertant, qui figurait dans la liste des mainteneurs, mais n’avait jamais publié auparavant pour node-ipc.

Upwind et d’autres rapports publics ont décrit une possible prise de contrôle faisant suite à l’expiration d’un domaine : l’attaquant aurait pu réenregistrer un domaine associé à l’adresse e-mail du compte du mainteneur, configurer la réception des e-mails, puis utiliser la procédure de récupération de compte npm pour prendre le contrôle du compte.

Les éléments disponibles pointent vers l’exploitation de l’identité d’un mainteneur disposant de droits de publication sur npm. Selon les analyses publiques, un domaine de messagerie expiré associé au mainteneur aurait pu faciliter la récupération du compte, mais l’enquête est toujours en cours. Cette distinction est importante : elle suggère qu’il n’était pas nécessaire de compromettre le registre npm, et que le dépôt source du projet ou son pipeline CI/CD n’était peut-être pas le vecteur initial de l’attaque.

Vecteur d’attaque et comportement malveillant

La charge utile semble avoir été insérée dans node-ipc.cjs, le bundle CommonJS utilisé par les personnes qui chargent le package avec require("node-ipc"). Selon les analyses publiques, le point d’entrée ESM n’a pas été modifié de la même manière.

Contrairement à de nombreux incidents de logiciels malveillants sur npm, cette compromission ne se serait pas appuyée sur des scripts exécutés lors de l’installation, comme preinstall, install ou postinstall. La logique malveillante aurait plutôt été ajoutée sous la forme d’une expression de fonction immédiatement invoquée. Le code pouvait donc s’exécuter au moment de l’importation du package, et pas uniquement lors de l’installation de la dépendance.

• Empreinte de l’environnement et de l’hôte

• Recherche d’identifiants locaux et de fichiers développeur sensibles

• Collecte d’identifiants cloud, de clés SSH, de jetons Kubernetes, de la configuration GitHub CLI, de l’état Terraform, d’identifiants de base de données, de l’historique du shell et de configurations d’outils d’IA et de développement

• Compression des données collectées

• Exfiltration des données vers une infrastructure contrôlée par l’attaquant

StepSecurity indique que la charge utile ciblait plus de 90 catégories d’identifiants et exfiltrait les données collectées vers une infrastructure utilisant le domaine azurestaticprovider[.]net.

Qui pourrait être concerné

1. Votre projet dépend directement de node-ipc et utilise la version 9.1.6, 9.2.3 ou 12.0.1.

2. Votre projet dépend d’une dépendance qui a récupéré l’une des versions concernées comme dépendance transitive.

3. Votre pipeline CI/CD, votre build de conteneur, votre poste de travail de développement ou votre cache de packages a installé l’une des versions malveillantes.

4. Vous utilisez des plages semver qui auraient pu sélectionner automatiquement l’une des versions concernées, comme ^9, ~9.1, ~9.2, ^12, ou des installations sans version épinglée.

5. Vous avez exécuté des chemins de code qui chargeaient node-ipc via la résolution CommonJS.

La présence d’une version dans un fichier de verrouillage ne prouve pas que le code malveillant a été exécuté, mais elle justifie une enquête. Si le package a été installé dans un environnement de développement ou CI/CD où des secrets étaient accessibles, partez du principe que des identifiants ont pu être exposés.

Conseils de détection

Vérifiez votre application avec la Snyk CLI en l’exécutant à la racine de votre projet.

snyk test

Si vous surveillez votre application dans l’interface Web de Snyk, vous recevrez automatiquement une alerte.

Sinon, vérifiez les arbres de dépendances et les fichiers de verrouillage pour repérer les versions concernées :

npm ls node-ipc

npm ls node-ipc --all 2>/dev/null | grep -E '9\.1\.6|9\.2\.3|12\.0\.1'

grep -E '"node-ipc".*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.json

grep -E 'node-ipc@(9\.1\.6|9\.2\.3|12\.0\.1)' yarn.lock

grep -E 'node-ipc.*9\.1\.6|9\.2\.3|12\.0\.1' pnpm-lock.yaml

find . -path '*/node_modules/node-ipc/node-ipc.cjs' -exec ls -lh {} \;

Parmi les indicateurs réseau et hôte signalés figurent les connexions sortantes vers sh.azurestaticprovider[.]net, le trafic sortant vers 37.16.75[.]69, un trafic UDP/53 inattendu provenant des processus d’application ou de build, des répertoires temporaires correspondant au modèle $TMPDIR/nt-*, ainsi que des processus ou processus enfants utilisant l’indicateur d’environnement __ntw=1 . Ces indicateurs peuvent évoluer à mesure que l’infrastructure de l’attaquant est démantelée ou renouvelée. Leur absence ne doit donc pas être considérée comme une preuve que votre environnement est sûr.

Mesures d’atténuation et réponse

Supprimez les versions malveillantes

• Épinglez node-ipc sur une version dont l’innocuité est établie.

• Actualisez les fichiers de verrouillage.

• Videz les caches de packages locaux et ceux de la CI, où les archives malveillantes peuvent persister.

• Reconstruisez les artefacts à partir d’arbres de dépendances sains.

Identifiez tous les environnements où le package a été installé

• Ordinateurs portables des développeurs

• Exécuteurs CI

• Conteneurs de build

• Registres d’artefacts internes

• Workers de build éphémères

• Systèmes de production, si des imports à l’exécution ont eu lieu

Renouvelez les secrets exposés

• Jetons npm

• Jetons GitHub

• Identifiants des fournisseurs cloud

• Clés SSH

• Secrets CI/CD

• Jetons Kubernetes et fichiers kubeconfig

• Identifiants de base de données

• Identifiants d’accès à l’état Terraform

• Identifiants d’outils d’IA et de développement

Révoquez les sessions et examinez les journaux d’accès

• Examinez les journaux d’audit cloud.

• Vérifiez les journaux d’audit de votre organisation GitHub.

• Examinez l’activité du compte npm et l’historique des publications de packages.

• Recherchez tout comportement inhabituel dans les tâches CI/CD, les nouveaux secrets, les nouvelles clés de déploiement ou les publications de packages inattendues.

Sécurisez la consommation des packages

• Utilisez des fichiers de verrouillage et des builds déterministes.

• Évitez d’utiliser automatiquement les versions de packages récemment publiées dans les systèmes de build de production.

• Envisagez de mettre en place des délais avant les mises à jour de dépendances ou des politiques de proxy de packages internes.

• Imposez l’authentification multifacteur aux personnes qui publient sur npm.

• Supprimez les mainteneurs inactifs et les domaines de messagerie expirés des projets open source.

• Surveillez les changements de comptes de mainteneurs et les nouvelles publications après de longues périodes d’inactivité.

• Analysez et surveillez vos applications en continu avec Snyk pour détecter les vulnérabilités

Pourquoi cet incident est important

Cet incident illustre une nouvelle fois que les attaquants ciblent les relations de confiance qui permettent aux écosystèmes open source de fonctionner. Pour être efficace, le package malveillant n’avait pas besoin de perturber le fonctionnement des applications. En préservant les fonctionnalités attendues tout en dérobant discrètement des identifiants, l’attaquant a augmenté les chances que les builds compromis et les environnements de développement continuent à fonctionner normalement.

Il met également en lumière une faiblesse récurrente de la chaîne d’approvisionnement : les packages dormants ou peu maintenus peuvent conserver une large portée dans l’écosystème, même après de longues périodes d’inactivité. Si l’identité d’un ancien mainteneur peut être récupérée, détournée ou exploitée, les attaquants peuvent publier des versions malveillantes dans des graphes de dépendances sans toucher aux systèmes de gestion du code source ou CI/CD.

Évaluation actuelle

Au vu des informations disponibles, cet incident doit être traité comme une compromission critique de la chaîne d’approvisionnement npm, présentant un risque majeur de vol d’identifiants dans les environnements de développement et CI/CD. Les versions actuellement confirmées comme affectées sont node-ipc@9.1.6, node-ipc@9.2.3 et node-ipc@12.0.1. Le vecteur d’attaque probable est l’exploitation du compte d’un mainteneur disposant de droits de publication, peut-être grâce à la récupération d’un domaine de messagerie de mainteneur expiré. L’enquête sur la cause première est toutefois toujours en cours.

Les équipes doivent immédiatement déterminer si une version concernée a été installée, renouveler les secrets accessibles depuis les environnements exposés et surveiller toute tentative d’exploitation ultérieure des identifiants volés.