24 paquets npm malveillants détournent des miroirs pour du phishing ClickFix

Une attaque qui exploite la confiance des développeurs

Des chercheurs en sécurité d'OX Security ont mis au jour une campagne inédite impliquant 24 paquets npm malveillants. Leur originalité ne réside pas dans la compromission de chaînes de build ou l'injection de code malveillant dans des bibliothèques populaires, mais dans une mécanique bien plus subtile : exploiter la réputation des plateformes de mirroring pour héberger des pages de phishing sans jamais toucher au code des développeurs.

Le schéma est le suivant : chaque paquet ne contient qu'un unique fichier HTML conçu pour imiter à la perfection une page de vérification Cloudflare. Ce fichier est ensuite automatiquement copié par les services de mirroring comme UNPKG ou npmmirror, qui répliquent l'intégralité du contenu du registre npm. La page frauduleuse se retrouve alors accessible via une URL qui inclut le domaine unpkg.com ou npmmirror.com — deux domaines parfaitement légitimes aux yeux de n'importe quel filtre de sécurité.

La technique ClickFix, popularisée depuis 2024, consiste à convaincre un utilisateur d'exécuter lui-même une commande malveillante. La page affiche un message de type « Une erreur s'est produite, copiez cette commande dans PowerShell pour résoudre le problème ». L'utilisateur, convaincu qu'il s'agit d'une vérification de sécurité légitime proposée par Cloudflare, exécute le code sans se méfier. Dans les campagnes avancées, cette commande télécharge et installe un infostealer, un RAT ou un ransomware.

Dans l'état actuel de cette campagne spécifique, selon OX Security, le lien de redirection finale pointe vers le site légitime de ChatGPT — probablement en phase de test ou pour valider la viabilité du canal avant weaponisation complète. Cette prudence tactique est caractéristique des opérateurs chevronnés qui cherchent à maximiser la durée de vie de leur infrastructure avant d'activer la charge utile réelle.

Chacun des 24 paquets généraient entre 50 et 300 téléchargements hebdomadaires avant leur retrait, ce qui représente une surface d'exposition non négligeable. Le vecteur de diffusion des URL ne passe pas forcément par PyPI ou npm directement : les attaquants peuvent promouvoir ces liens via des forums de développeurs, de faux tutoriels sur GitHub, des publications LinkedIn ou des messages directs sur Discord.

L'aspect le plus préoccupant de cette attaque est son faible coût pour l'attaquant. Publier un paquet sur npm est gratuit, prend moins de cinq minutes, et tire parti d'une infrastructure de mirroring mondiale gérée par des tiers. Le registre npm lui-même n'héberge techniquement pas la page malveillante : c'est le miroir qui la sert, rendant la détection et le retrait plus lents.

BleepingComputer et The Hacker News rapportent que npm a supprimé les paquets identifiés, mais le registre traite plus d'un million de publications par an. La modération automatisée reste insuffisante pour détecter du HTML non exécutable embarqué dans un paquet — les scanners traditionnels cherchent du JavaScript malveillant, pas des fichiers HTML autonomes.

Cette campagne s'inscrit dans une tendance de fond : les attaquants ne cherchent plus à compromettre les bibliothèques elles-mêmes, trop surveillées depuis les incidents SolarWinds et XZ Utils, mais à détourner la confiance implicite accordée aux domaines d'hébergement associés. La même logique a été appliquée à GitHub Pages, GitLab Pages et Cloudflare Pages dans d'autres campagnes récentes.

Pourquoi ce vecteur remet en question la confiance dans les miroirs de paquets

La supply chain logicielle a fait l'objet d'investissements massifs en matière de sécurité depuis 2021. Les entreprises ont déployé des outils de contrôle des dépendances (SBOM, Dependabot, Renovate), des politiques de version pinning strictes, et des scanners de secrets dans leurs pipelines CI/CD. Ces mesures sont pertinentes contre l'injection de code malveillant dans une bibliothèque — mais elles ne couvrent pas le scénario où c'est l'URL d'un fichier statique qui est détournée.

Le modèle de confiance des développeurs envers les domaines npm, UNPKG et leurs équivalents est profondément ancré. Ces domaines figurent dans des listes d'autorisation de nombreux proxies d'entreprise. Un employé recevant par email ou Slack un lien unpkg.com/package-name/dist/index.html ne le suspectera pas instinctivement, d'autant que le contenu semble provenir d'un projet open source.

Pour les équipes de sécurité, cette campagne introduit un angle mort : les solutions DLP et les proxies web categorisent UNPKG comme un domaine de développement sûr. Les équipes SOC ne surveillent généralement pas les accès à ce type de domaine avec le même niveau d'alerte que des domaines inconnus. Il faudra probablement attendre que des attaques avec charges utiles réelles soient documentées pour que les politiques de filtrage s'adaptent.

Du côté de la réglementation, la directive NIS2 et le règlement CRA (Cyber Resilience Act) européen imposent aux éditeurs de logiciels une responsabilité accrue sur la sécurité de leurs chaînes d'approvisionnement. Cette campagne illustre que les menaces supply chain ne se limitent pas à la compromission de code : l'ingénierie sociale via des actifs d'infrastructure légitimes entre dans le périmètre que les organisations doivent désormais couvrir.

Ce qu'il faut retenir

• Des URL provenant de domaines légitimes comme UNPKG ou npmmirror peuvent héberger des pages de phishing : la confiance implicite dans un domaine ne suffit pas.
• La technique ClickFix cible l'utilisateur final, pas le développeur : les équipes de sensibilisation doivent inclure ce vecteur dans leurs formations.
• Bloquer les fichiers HTML statiques servis depuis des CDN npm dans les proxies d'entreprise est une mesure de durcissement préventive immédiate à évaluer.