Le 18 juillet 2026, l'équipe de Socket Security publie un rapport qui met le feu aux poudres dans la communauté JavaScript : 40 packages npm malveillants, actifs depuis plusieurs semaines, imitaient des bibliothèques React et Vue parmi les plus téléchargées au monde. Leur objectif ? Aspirer vos variables d'environnement au moment précis où vous tapez npm install.
La technique du typosquatting : exploiter l'erreur de frappe
Le typosquatting consiste à publier un package dont le nom ressemble à s'y méprendre à celui d'une bibliothèque légitime. Un caractère inversé, un tiret déplacé, une lettre en double : l'erreur est humaine, et les attaquants le savent.
Parmi les noms identifiés dans cette campagne : react-router-dmo (au lieu de react-router-dom), vuex-stroe, vue-routes ou encore axios-htttp. Tous avaient une description soignée, un README crédible et parfois même une fausse page npm avec plusieurs centaines d'étoiles artificielles.
Ce que le package faisait à l'installation
Chaque package contenait un script postinstall discret. Au moment où npm complète l'installation, le script se déclenche, collecte le contenu de process.env (clés API, tokens, credentials de base de données, variables CI) et envoie le tout à un serveur distant via une requête HTTP.
Le payload était minimal, sans dépendances externes, difficile à détecter par une analyse statique basique. Socket l'a repéré grâce à son analyse comportementale : le package demandait un accès réseau sortant immédiatement après l'installation, ce qui n'a aucune raison légitime d'exister dans une bibliothèque UI.
L'ampleur : des milliers de téléchargements avant détection
Selon le rapport Socket, les packages avaient cumulé entre 3 000 et 15 000 téléchargements chacun avant d'être signalés. Plusieurs étaient en place depuis 3 à 5 semaines. npm a procédé au retrait dans les 24 heures suivant la notification, mais le mal était potentiellement fait pour les projets qui avaient intégré ces packages en production ou dans leurs pipelines CI/CD.
Comment se protéger
Cette campagne illustre un risque que npm audit ne couvre pas : les CVE connues, oui, mais pas les packages malveillants nouveaux qui n'ont encore reçu aucun signalement. Voici les bonnes pratiques à adopter.
- Vérifier le nom exact du package avant d'installer, en particulier dans les scripts de CI copiés depuis des tutoriels ou des forums.
- Utiliser Socket ou Snyk qui analysent le comportement déclaré du package avant installation.
- Committer et vérifier son
package-lock.jsonou sonyarn.lock: une mise à jour non intentionnelle de lockfile en CI est un signal d'alerte. - Activer les alertes Dependabot sur GitHub pour être notifié dès qu'un package installé reçoit un signalement de sécurité.
- Dans les environnements sensibles (CI/CD, serveurs de production), restreindre l'accès réseau sortant des scripts d'installation.
Le problème de fond : la confiance par défaut dans npm
npm héberge plus de 2,5 millions de packages. Publier en est simple et gratuit, sans vérification d'identité robuste. L'écosystème repose sur une confiance implicite qui devient un vecteur d'attaque à mesure que les projets accumulent des centaines de dépendances transitives.
Socket, Snyk, OSSF Scorecard ou encore le projet Alpha-Omega de la Linux Foundation travaillent sur des solutions : analyse comportementale, signature des packages, score de confiance calculé automatiquement. Mais la adoption reste partielle, et l'attaque de juillet 2026 rappelle que le problème n'est pas résolu.
- Socket Security Blog — Socket, 18 juillet 2026
- GitHub Security Advisories — GitHub, juillet 2026
