Un proxy pour contourner le pare-feu du lycée ? Le navigateur, lui, s’enrôlait discrètement dans un botnet. Selon les analyses de JFrog reprises le 14 juillet 2026 par The Hacker News, 148 paquets du registre npm ont servi à transformer les navigateurs de leurs victimes en relais d’attaque DDoS. Les modules se présentaient comme des proxys pour contourner des restrictions réseau, avec une cible assumée : les étudiants et les environnements scolaires.
Le montage repose sur un chargeur mutable, capable d’être réarmé par ses opérateurs sans publier de nouvelle version. En clair, on modifie la charge utile ou les paramètres de campagne sans laisser de trace visible dans le registre. De quoi compliquer sérieusement la vie des défenseurs.
Points clés
- 148 paquets npm se faisaient passer pour des proxys destinés aux étudiants
- Les navigateurs infectés servaient de relais dans une infrastructure DDoS
- Un chargeur mutable permet de réarmer la campagne sans republier de version
- JFrog recommande de surveiller dépendances transitives et trafic sortant anormal
Un proxy en vitrine, un relais DDoS en coulisses
Les paquets repérés par JFrog ne s’affichent pas comme des composants malveillants classiques. Ils se vendent comme des proxys web pour contourner des blocages, promesse assez alléchante pour un étudiant coincé derrière le pare-feu de son établissement. L’utilisateur croit installer un utilitaire. Son navigateur, lui, exécute une logique qui l’intègre à une infrastructure de DDoS.
Le cas s’ajoute à une série d’abus récents de l’écosystème npm. Début juillet 2026, JFrog documentait déjà d’autres campagnes de paquets déguisés en outils légitimes, dont des modules liés à Rollup. La logique change, le mode opératoire reste identique : exploiter la confiance accordée au registre et à toute la chaîne d’approvisionnement logicielle.
Un chargeur mutable qui esquive les mises à jour visibles
Le cœur technique de la campagne tient à ce chargeur mutable. Plutôt que de figer un comportement dans le paquet publié, les opérateurs gardent la main pour réarmer leur infrastructure sans republier quoi que ce soit. La version affichée sur le registre ne dit donc rien de l’état réel du code exécuté.
La menace ne se résume pas à un fichier malveillant statique. Elle repose sur un pilotage à distance, avec des paramètres et des charges utiles interchangeables. Pour les équipes de sécurité, cela impose de regarder au-delà des noms de paquets installés : comportements réseau, dépendances transitives et machines de développement qui auraient pu charger ces modules.
Ce qu’il faut surveiller dans les environnements npm
- les paquets installés manuellement ou via une dépendance transitive depuis npm ;
- les environnements de développement et de test, souvent plus exposés que la production ;
- les anomalies de trafic sortant depuis le navigateur ou les outils de build ;
- les paquets qui changent de comportement sans modification apparente de leur nom ni de leur description.
La leçon est aussi vieille que les registres publics : un paquet peut servir de façade à tout autre chose qu’une bibliothèque. Ici, un proxy vendu aux étudiants a masqué un botnet de navigateurs orienté DDoS, avec un mécanisme de contrôle pensé pour durer bien après la version qui l’a introduit.
