Les développeurs devraient envisager de ne plus utiliser les plateformes npm et yarn pour distribuer leur travail, explique dans un blog Oren Yomtov, chercheur chez Koi Security. Un avertissement lancé après la découverte de six failles zero day dans les gestionnaires de paquets. Selon lui, ces vulnérabilités pourraient donner aux pirates la possibilité de contourner les défenses recommandées en novembre dernière après la diffusion du vers Shai-Hulud à travers npm. Une attaque qui avait compromis plus de 700 paquets.

Les mesures tournent autour de deux axes. Le premier est de désactiver l’exécution des scripts sur le cycle de vie, des commandes déclenchées automatiquement lors de l'installation des paquets. Le second est d’enregistrer les contrôles d'intégrité des fichiers de verrouillage (package-lock.json, pnpm-lock.yaml, etc.) dans le contrôle de version (git). « Ces recommandations sont devenues la norme partout, depuis les guides de sécurité GitHub jusqu’aux documents de politique d'entreprise depuis le moins de novembre », a rappelé M. Yomtov, « car si le code malveillant ne peut pas s'exécuter lors de l'installation et que l’arborescence de dépendances est verrouillée, le travail du développeur est protégé ».

Une réponse déconcertante de GitHub

Si, comme l’a déclaré le chercheur par courriel à CSO, les conseils émis en novembre sont toujours valables, les vulnérabilités qu'il a découvertes, baptisées PackageGate, permettent aux pirates de contourner ces deux défenses et nécessitent d’être corrigées par toutes les plateformes. « Jusqu'à présent, les plateformes pnpm, vlt et Bun ont corrigé les failles de contournement, mais pas les plateformes npm et yarn », a fait remarquer l’expert. Il recommande donc aux développeurs JavaScript d'utiliser pnpm, vlt ou Bun. Celui-ci ajoute que, dans tous les cas, les développeurs devraient maintenir à jour le gestionnaire de paquets JavaScript qu'ils utilisent afin d’être sûr de disposer des derniers correctifs.

Microsoft, qui possède et supervise npm via GitHub, a renvoyé les questions concernant les vulnérabilités à GitHub. Dans un communiqué, l’éditeur a déclaré : « Nous travaillons activement à la résolution du problème signalé, car npm recherche activement les logiciels malveillants dans le registre. » En attendant, le chercheur invite les développeurs de projets à adopter les recommandations publiées dans ce blog après les attaques de Shai-Hulud. La déclaration note également qu'en septembre dernier, GitHub a annoncé un renforcement de la sécurité de npm, notamment en apportant des modifications à l'authentification et à la gestion des tokens. La société prévient par ailleurs que si un paquet installé via git contient un script de préparation, ses dépendances et devDependencies seront installées. « Comme nous l'avons indiqué lors du dépôt du ticket, il s'agit d'une conception intentionnelle qui fonctionne comme prévu. Lorsque les utilisateurs installent une dépendance git, ils font confiance à l'ensemble du contenu de ce référentiel, y compris ses fichiers de configuration. » Selon M. Yomtov cette explication qui s’appuie sur la « conception intentionnelle » est « déconcertante ».

Une vision incomplète des risques

Le chercheur précise que la vulnérabilité de contournement des scripts a été signalée via le programme de bug bounty de HackerOne le 26 novembre 2025. Alors que d'autres gestionnaires de paquets JavaScript ont accepté les rapports, npm a déclaré que la plateforme fonctionnait comme prévu et que la commande « ignore scripts » devait empêcher l'exécution de code distant non approuvé. « Nous n'avons pas écrit cet article pour blâmer qui que ce soit », a déclaré M. Yomtov dans son blog.

« Nous l'avons rédigé parce que l'écosystème JavaScript mérite mieux que cela et parce que les décisions de sécurité doivent être fondées sur des informations précises, et non sur des hypothèses de défense qui ne tiennent pas la route », a-t-il poursuivi. « Le conseil de base, qui consiste à désactiver les scripts et à valider les fichiers de verrouillage, reste valable. Mais ce n'est pas tout », a-t-il ajouté. « Tant que le problème des vulnérabilités PackageGate n'aura pas été entièrement résolu, les entreprises devront prendre leurs propres décisions éclairées en matière de risque. »