Confusion npx : les paquets qui ont oublié de revendiquer leur propre nom

En juillet 2025, je travaillais sur le prototype d'un nouveau projet et j'ai décidé d'essayer MikroORM. La documentation indiquait d'exécuter npx mikro-orm-esm pour les migrations. C'est ce que j'ai fait.

npm ERR ! code E404
npm ERR ! 404 Introuvable - GET https://registry.npmjs.org/mikro-orm-esm

Le paquet n'existe pas, c'est étrange ! Puis j'ai eu une idée : et si quelqu'un l'avait enregistré ? J'aurais vu :

Vous devez installer les paquets suivants :
mikro-orm-esm@1.0.0
Vous souhaitez continuer ? (y)

J'aurais juste frappé yTout le monde le fait. Et rien dans cette invite ne vous indique si vous êtes sur le point d'installer un logiciel malveillant ou un outil légitime.

Les documents faisaient référence à un paquet inexistant. Combien d'autres références phantom circulent ? Combien ont déjà été revendiquées par des pirates ? Je devais le savoir.

J'ai donc commencé à creuser. J'ai écrit des scripts pour analyser npm à la recherche des paquets référencés dans READMEet des scripts, mais jamais publiés. Des milliers de références croisées npx Invocations. J'en ai trouvé des dizaines. J'en ai revendiqué 14 avant que quelqu'un d'autre ne le fasse. Puis S1ngularity est arrivé, et la recherche a été mise de côté.

Six mois plus tard, je me suis souvenu de mes recherches grâce à la communauté qui menait des recherches similaires. J'ai finalement vérifié le nombre de téléchargements : 121 539 téléchargements !

Les gens avaient tapé ces commandes inexistantes des milliers de fois par semaine. Pendant des mois. Alors que les paquets restaient là à collecter des données. 

Six mois de données

Les téléchargements n'ont pas stagné. Ils ont augmenté. Ils ont démarré lentement fin juillet. Le pic récent a atteint 4 236 téléchargements en une seule journée (le 16 janvier 2026).

• Total: 121 539 téléchargements pour 128 paquets
• Moyenne hebdomadaire: 3 903
• Journée record: 4 236 téléchargements (16 janvier 2026)

Remarque rapide concernant le bruit : chaque fois que vous publiez une nouvelle version d'un paquet, celle-ci est automatiquement téléchargée entre 60 et 100 fois par les scanners de sécurité et les miroirs. Il s'agit là du bruit de base par version. Les paquets comportant plusieurs versions accumulent rapidement du bruit. Tout ce qui dépasse systématiquement ce seuil correspond à une utilisation réelle.

Remarquez-vous la baisse vers la fin décembre ? Les vacances. Même phantom prennent congé à Noël.

Les trois grands

Trois paquets représentent 79 % de tous les téléchargements :

• openapi-generator-cli: 48 356 téléchargements (paquet réel : @openapitools/openapi-generator-cli)
• cucumber-js: 32 110 téléchargements (paquet réel : @concombre/concombre)
• depcruise: 15 637 téléchargements (paquet réel : cruiser de dépendance)

openapi-generator-cli a enregistré 3 994 téléchargements au cours des 7 derniers jours seulement. Cela signifie que près de 4 000 fois, quelqu'un a essayé d'exécuter une commande qui n'existe pas. En une semaine.

La longue traîne

Les autres paquets ayant fait l'objet d'un nombre important de téléchargements :

• jsdoc2md: 4 641 téléchargements
• grpc_tools_node_protoc: 4 518 téléchargements
• vue-demi-commutateur: 1 166 téléchargements
• guide de style: 805 téléchargements
• mikro-orm-esm: 314 téléchargements
• pvbase64: 142 téléchargements
• cromwell: 106 téléchargements

‍

Vous vous souvenez de cette base de référence de 60 à 100 téléchargements par version ? Un package comportant 3 versions pourrait générer entre 180 et 300 téléchargements de bruit pur. fathym avec un total de 83 téléchargements, ce n'est probablement que du bruit. Mais mikro-orm-esm Avec 314 ? Même en tenant compte des multiples versions, ce sont de véritables tentatives.

guide de style avec 805 téléchargements, cela signifie des centaines d'exécutions réelles. Il pourrait s'agir de CI/CD qui le frappe à plusieurs reprises. Il pourrait s'agir de dizaines de développeurs différents. Quoi qu'il en soit, il s'agit d'une utilisation réelle d'un paquet qui ne devrait pas exister.

Comment nous les avons trouvés

Nous gérons un miroir complet du registre npm chez Aikido. Analysé tous les package.json et README dans l'ensemble du registre. Extrait npx commandes. Recoupées avec ce qui est réellement enregistré. Nous avons également effectué une recherche dans le code GitHub afin de déterminer dans quelle mesure ces phantom apparaissent dans la nature, dans la documentation, les configurations CI, les scripts, partout où les développeurs pourraient y faire référence.

Trois points de données pour chaque paquet :

• Références dans le registre: combien de paquets npm mentionnent cette commande dans leur fichier package.json ou README
• Résultats GitHub: combien de fichiers de code ou de référentiels font référence à cette commande sur GitHub ?
• Téléchargements: combien de fois les gens ont-ils réellement essayé de l'exécuter ?

Nous en avons réclamé 14 en juillet 2025. Lorsque j'ai repris mes recherches en janvier, nous avons élargi notre analyse et en avons trouvé beaucoup d'autres. À ce stade, nous avons réclamé 128 colis au total.

‍

Quelques tendances à noter :

Principaux vecteurs d'attaque (plus de 10 000 téléchargements) : openapi-generator-cli, cucumber-js, et depcruise tous montrent une forte corrélation entre les références npm, les mentions GitHub et les téléchargements réels. Ceux-ci seraient dévastateurs entre les mains d'un pirate.

Exposition élevée, faible conversion : guide de style compte 246 références npm et 286 résultats GitHub, mais seulement 805 téléchargements. git-scripts-pré-push compte 126 références, mais seulement 93 téléchargements. La visibilité n'est pas toujours synonyme d'exécution.

Vecteurs de documentation uniquement : mikro-orm-esm n'a aucune référence dans les paquets npm, mais 80 résultats GitHub et 314 téléchargements. Preuve que la documentation seule peut générer des centaines d'installations, même sans aucune référence dans l'écosystème npm.

Pourquoi cela est dangereux

L'attaque est simple.

Un attaquant enregistre le paquet. Ajoute un post-installation script qui exfiltre les variables d'environnement : jetons npm, cloud , clés API, tout ce qui traîne. Puis attend.

Au plus fort de l'attaque, cela représente potentiellement environ 4 000 machines compromises par semaine. Postes de travail de développeurs. Serveurs CI. Environnements de compilation. Beaucoup fonctionnent probablement avec des identifiants dans des variables d'environnement. Pas besoin de phishing. Pas de compromission de la chaîne d'approvisionnement des paquets existants. Il suffit de revendiquer le nom et d'attendre que npx vous amène les victimes.

Lorsque quelqu'un exécute la commande, il voit :

Vous devez installer les paquets suivants :
openapi-generator-cli@1.0.0
Vous souhaitez continuer ? (y)

La fenêtre contextuelle n'indique pas qui l'a publiée. Elle n'indique pas quand. Elle n'indique pas si c'est ce que vous recherchez. Vous pouvez voir cette fenêtre contextuelle régulièrement pour des outils légitimes. La mémoire musculaire prend le dessus, car nous sommes humains. Vous tapez y, comme tout le monde. C'est tout. C'est toute l'attaque.

Nous avons comblé 128 lacunes au cours de plusieurs cycles. Nous avons corrigé les cas les plus graves. Mais il en reste encore des milliers.

Remarque sur les protections de npm

npm dispose d'une protection contre le typosquatting. Lorsque nous avons essayé de revendiquer certains noms, npm les a rejetés en raison d'erreurs de similitude. Des noms tels que rsbuild, vuedoc, napi, t-ci étaient tous trop proches des paquets existants. C'est une bonne chose. Cela signifie que npm bloque activement les tentatives évidentes d'usurpation.

Mais ces phantom ne sont pas des fautes de frappe. Ce sont des noms qui n'ont jamais été enregistrés. Le contrôle de similitude de npm ne les détecte pas, car il n'y a rien à quoi ils pourraient « ressembler ».

Ce que vous devez faire

Utilisez npx --no-install

npx --no-install votre-commande

Cela oblige npx à n'utiliser que des binaires locaux. Pas de repli vers le registre. Si ce n'est pas installé, cela échoue. C'est ce que vous voulez.

Installez explicitement les outils CLI. Ne vous fiez pas à npx pour les aller chercher :

{
  "devDependencies": {
    "@openapitools/openapi-generator-cli": "^2.7.0"
  }
}

Vérifiez avant de lancer. La documentation indique d'exécuter npx Quelque chose ? Vérifiez d'abord que le paquet existe réellement. Vérifiez qu'il s'agit du bon. En particulier dans CI/CD.

Réclamez votre espace de noms. Si vous gérez un outil CLI, enregistrez les alias et les fautes d'orthographe évidents. C'est une assurance peu coûteuse contre toute tentative malveillante de la part d'une autre personne.

Comment savoir si vous êtes concerné

Si vous Aikido , vérifiez votre flux central et filtrez les problèmes liés aux logiciels malveillants. Toute vulnérabilité phantom apparaîtra comme un problème critique 100/100 dans le flux. Aikido vos référentiels chaque nuit, mais nous vous recommandons également de lancer une analyse complète.

Si vous n'êtes pas encore Aikido , créez un compte gratuit et connectez vos dépôts. Notre couverture anti-malware exclusive est incluse dans l'offre gratuite (aucune carte de crédit requise).

Pour vous protéger à l'avenir, pensez à utiliser Aikido (open source), un wrapper sécurisé pour npm, npx, yarn et pnpm. SafeChain s'intègre à vos workflows actuels, intercepte les commandes d'installation de paquets et vérifie les paquets par rapport à Aikido (notre renseignement sur les menaces open source renseignement sur les menaces) avant qu'ils n'atteignent votre machine. Bloquez les menaces dès leur apparition.

Les mathématiques

121 539 téléchargements en sept mois. 3 903 par semaine en moyenne. Pic de 4 236 en une seule journée. 128 paquets réclamés au total (14 en juillet, le reste en janvier).

L'écosystème npm compte des millions de paquets. Les développeurs exécutent des commandes npx des milliers de fois par jour. La différence entre « paramètre par défaut pratique » et « exécution de code arbitraire » réside dans un nom de paquet non revendiqué.

‍