La chaîne d’approvisionnement logicielle est de nouveau ciblée par une attaque visant l’écosystème JavaScript. Cette fois, des cybercriminels ont compromis dix packages npm et publié douze versions contenant un code malveillant dissimulé. Repérée par Sonatype Research Labs le 4 novembre 2026, cette campagne est associée au malware PolinRider.
Le mécanisme repose sur une technique inhabituelle : la blockchain Ethereum sert à retrouver l’adresse d’un serveur contrôlé par les attaquants. Le code malveillant peut alors télécharger d’autres composants et les exécuter sur les systèmes concernés. Sonatype suit cette découverte sous la référence sonatype-2026-010515. sonatype.com+1
Dix packages npm compromis, douze versions malveillantes
Les packages concernés proposent des fonctionnalités variées. Certains servent à intégrer Redux, gérer des API de santé ou suivre l’activité d’un navigateur. D’autres fournissent des utilitaires et des composants destinés aux applications serveur.
Cette diversité rend la campagne particulièrement préoccupante. Les développeurs peuvent intégrer ces dépendances sans soupçonner qu’elles contiennent un mécanisme d’exécution malveillant.
Les dix packages identifiés et leurs versions concernées sont les suivants :
| Package npm | Version(s) compromise(s) |
|---|---|
@adminide-stack/client-redux | 0.0.16-18 |
@adminide-stack/health-api-server | 0.0.18-alpha.465 |
@adminide-stack/user-activity-browser | 1.1.3-alpha.114 |
@adminide-stack/utils | 0.0.16-129, 0.0.16-130 |
server-hemera-mongo | 0.0.15, 0.0.16 |
cdeops | 13.5.31 |
@adminide-stack/forms-core | 5.1.9-alpha.3 |
@adminide-stack/yantra-help-browser | 12.0.194 |
@cdmbase/wiki-browser | 12.0.18-alpha.53 |
@pubngo-stack/help-browser | 12.0.23-alpha.3 |
Les chercheurs ont identifié deux méthodes de dissimulation. Six versions utilisent un chargeur encodé en Base64, exécuté avec eval(atob(...)). Les six autres reposent sur une permutation de caractères et le constructeur JavaScript Function. Ces techniques rendent le code malveillant moins évident lors d’une inspection rapide des fichiers. (Analyse technique de Sonatype)
Ethereum détourné pour localiser les serveurs malveillants
La particularité de cette attaque réside dans son mécanisme de communication. Au lieu d’intégrer directement une adresse de serveur dans les packages, les attaquants utilisent une adresse de portefeuille Ethereum fixe : 0x1eef0849eda15d87f64e51c73c8442cf3c8bcef3.
Au chargement, le code interroge des serveurs RPC publics Ethereum pour retrouver une transaction envoyée par ce portefeuille. Si les serveurs interrogés ne répondent pas, il utilise l’API Blockscout comme solution de secours.
Le chargeur extrait ensuite deux adresses IPv4 des données de la transaction. La première sert à contacter le serveur principal. La seconde constitue une adresse de remplacement.
Le malware télécharge alors du JavaScript encodé par XOR depuis le serveur distant. Les communications utilisent les chemins /0x/cls et /0x/ls, sur le port TCP 443, mais en HTTP non chiffré.
Le code récupéré depuis /0x/cls s’exécute dans l’application compromise. Il est également lancé dans un processus Node.js détaché avec la commande node -i. Le second chemin, /0x/ls, alimente uniquement ce processus indépendant. Celui-ci peut donc continuer à fonctionner même après la fermeture de l’application initiale.
Ce fonctionnement transforme Ethereum en un mécanisme de résolution d’infrastructure malveillante. L’attaquant peut modifier l’adresse du serveur en publiant une nouvelle transaction, sans republier les packages npm. Bloquer une adresse IP ne suffit donc pas à neutraliser durablement le dispositif. (Sonatype Research Labs)
Une attaque qui contourne la désactivation des scripts npm
De nombreuses attaques contre npm s’appuient sur les scripts preinstall ou postinstall. Ces mécanismes permettent d’exécuter du code pendant l’installation d’une dépendance. Certaines équipes les désactivent pour réduire les risques.
Cependant, les packages concernés par cette campagne ne dépendent pas de ces scripts. Le code malveillant s’exécute lorsque l’application charge le module compromis. Dans le cas de server-hemera-mongo, l’injection se trouve dans dist/main.js et s’active au démarrage du service.
Désactiver les scripts d’installation ne protège donc pas contre cette méthode. Le risque concerne aussi bien les postes des développeurs que les serveurs de compilation et les environnements de production.
Cette technique s’inscrit dans une activité déjà documentée autour de PolinRider. Le 27 octobre 2026, GitGuardian avait signalé l’utilisation du même portefeuille Ethereum dans des chargeurs découverts au sein de dépôts GitHub compromis. Les chercheurs avaient également observé les chemins /0x/cls et /0x/ls.
Une autre analyse de Greenflagged a identifié l’adresse IP 95.135.181.151 comme serveur annoncé par une transaction du portefeuille le 3 novembre. GitGuardian avait déjà relevé cette adresse comme infrastructure de secours dans un script de persistance associé à PolinRider. (Rapport GitGuardian ; analyse Greenflagged)
Il convient toutefois de distinguer les liens techniques d’une attribution formelle. Ces éléments rapprochent les attaques, mais ne prouvent pas que PolinRider et GhostAction sont pilotés par le même opérateur. GitGuardian estime notamment que l’opérateur de GhostAction pourrait avoir repris un chargeur PolinRider déjà disponible publiquement.
PolinRider : une menace connue depuis 2025
Les investigations montrent que PolinRider ne constitue pas une menace récente. OpenSourceMalware a retrouvé des composants associés à ce malware dans des packages npm publiés dès mai 2025.
Ces premières versions contenaient notamment un cheval de Troie d’accès à distance et un voleur d’informations Python. Les composants visaient entre autres les navigateurs, les portefeuilles électroniques, les dépôts Git et les espaces de stockage cloud.
Cette découverte repousse donc l’ancienneté connue de certaines composantes de PolinRider. Elle montre également que les attaquants font évoluer leurs méthodes pour compromettre les environnements de développement. (OpenSourceMalware)
Comment les entreprises peuvent-elles se protéger ?
Les organisations qui utilisent npm doivent vérifier leurs dépendances sans attendre. Sonatype recommande notamment de rechercher les versions compromises dans les fichiers de verrouillage, les miroirs internes, les caches et les historiques de compilation.
Plusieurs mesures permettent de limiter les conséquences :
- Identifier les versions compromises : examiner
package-lock.json,yarn.locketpnpm-lock.yaml, y compris les dépendances indirectes. - Bloquer les packages concernés : empêcher leur téléchargement depuis les registres internes et supprimer leurs copies des caches.
- Remplacer les dépendances : utiliser uniquement des versions dont l’intégrité a été vérifiée.
- Rechercher les traces d’exécution : examiner les journaux de processus et de réseau pour identifier les chargements suspects et les processus
node -idétachés. - Surveiller les communications : rechercher les requêtes HTTP vers le port 443 utilisant
/0x/clsou/0x/ls, ainsi que les en-têtesSec-Vassociés aux chargeurs. - Renouveler les secrets exposés : remplacer les jetons npm, les accès aux dépôts Git, les clés cloud et les secrets accessibles depuis les environnements concernés.
Un point mérite une attention particulière : retrouver une version compromise dans un fichier de verrouillage ne signifie pas nécessairement que le code malveillant a été exécuté. Il faut vérifier si l’application a effectivement chargé le fichier infecté.
À l’inverse, une erreur d’importation ne garantit pas l’absence de compromission. Le code malveillant peut s’être exécuté avant que l’importation échoue.
Si l’exécution est confirmée, l’organisation doit considérer l’hôte comme compromis et engager une investigation complète. Elle doit notamment déterminer quelles ressources et quels identifiants étaient accessibles au processus Node.js. Le guide de réponse aux incidents de Sonatype fournit des recommandations complémentaires.
Conclusion
L’affaire PolinRider rappelle que les packages open source peuvent devenir des vecteurs d’intrusion particulièrement efficaces. En exploitant la confiance accordée aux dépendances npm, les attaquants peuvent introduire du code malveillant directement dans les applications.
L’utilisation d’Ethereum complique davantage la détection et le blocage de l’infrastructure. Elle permet aux opérateurs de modifier leurs serveurs sans toucher aux packages déjà distribués.
Pour les équipes informatiques, la sécurité de la chaîne d’approvisionnement logicielle ne peut donc plus se limiter à vérifier les scripts d’installation. Il devient essentiel de contrôler le code réellement exécuté, de surveiller les dépendances et de protéger les environnements de développement comme les infrastructures de production.
SOURCE : CybersecurityNews
