Incident de publication automatisée de packages IndonesianFoods dans l’écosystème NPM lié à une arnaque de farming de récompenses crypto

« Les conclusions d’Amazon s’inscrivent dans le prolongement direct de l’activité du ver IndonesianFoods que notre équipe a analysée : elles nous rappellent que l’automatisation de type IA facilite la publication à grande échelle de centaines de milliers de packages inutiles ou risqués. Les développeurs devraient s’appuyer sur des contrôles automatisés de l’état des dépendances et sur l’analyse comportementale, plutôt que sur des vérifications manuelles : il faut signaler les packages peu téléchargés, les contenus issus de modèles réutilisés et les vagues soudaines de publications avant qu’ils n’intègrent le processus de build. Les opérateurs de registres doivent eux aussi évoluer : ils doivent détecter de manière proactive les téléversements massifs, les modèles réutilisés avec des empreintes identiques et les anomalies dans l’état des métadonnées afin d’interrompre ces campagnes à la source. »

- Manoj Nair, directeur de l’innovation, Snyk

En bref

En novembre 2025, des chercheurs en sécurité ont identifié une forte hausse des publications de packages présentant des structures et des schémas de nommage similaires sur le registre NPM. Alors que les premiers signalements évoquaient un ver, cette activité semble plutôt être le vestige d’un script d’automatisation resté inactif pendant longtemps et associé à un système de récompenses en cryptomonnaie. 

Remarque : aucun exploit actif dans la nature n’a été confirmé, et les packages concernés présentent actuellement un risque minime. 

Il semble qu’un développeur ait écrit un script de spammeur, puis l’ait téléversé dans le cadre de l’opération de spam ; il s’agit des vestiges d’un script de publication automatisée, initialement lié à un ancien projet de farming de récompenses en cryptomonnaie. Il existe cinq packages distincts au total (reproduits en milliers d’exemplaires aux noms légèrement différents), dont la seule fonctionnalité malveillante consiste à publier des packages en continu. Chaque package contenant le script de publication affiche en moyenne seulement 18 téléchargements par mois. 

Cela dit, cet événement souligne la nécessité constante de maintenir une hygiène rigoureuse des dépendances et des pratiques fiables pour les registres.

Composant et écosystème concernés

L’incident concerne un groupe de packages NPM publiés sous plusieurs comptes aux noms très proches, à l’aide de modèles de code cohérents (souvent basés sur Next.js) et présentant de légères différences de structure selon les versions et les noms (par exemple, des suffixes tels que -wekto, -riris et -z3n). Les packages semblent avoir été publiés en masse au fil du temps, probablement à l’aide de scripts automatisés, plutôt qu’installés et exploités dans des systèmes actifs. Ils font référence à une ancienne campagne de récompenses en crypto (tea.xyz), mais ne présentent aucun signe confirmé d’exécution malveillante ni d’auto-propagation après installation.

Chronologie de l’incident

• Fin 2023 : plusieurs packages de base sont publiés (par exemple, vointea et voinzaril) ; ils contiennent initialement du code d’application Web apparemment inoffensif.

• Peu après, une activité de publication en masse apparaît : des centaines ou des milliers de packages dérivés utilisent des modèles de code similaires avec des suffixes renommés.

• Pause de plusieurs mois : l’activité s’interrompt.

• Deux mois plus tard : une nouvelle série de publications massives a lieu (les suffixes changent).

• 11 novembre 2025 : des discussions émergent au sein de la communauté ; elles évoquent jusqu’à environ 44 000 packages concernés (même si le nombre réel de publications en masse pourrait être inférieur).

• 12 novembre 2025 : l’analyse indique que les packages sont les vestiges inoffensifs d’une ancienne campagne et non des logiciels malveillants actifs.

Packages NPM concernés

• Environ cinq packages « racines » distincts ont été identifiés (vointea, voinzaril et des variantes avec les suffixes wekto, riris et z3n).

• Le nombre de copies est estimé à plusieurs milliers (par exemple, environ 4 000 à 5 000 packages), plutôt qu’à des dizaines de milliers ; les estimations plus élevées tiennent compte d’autres versions mineures au sein des packages.

• Le nombre moyen de téléchargements de ces packages est extrêmement faible (généralement moins de 20 par mois).

• Aucune compromission confirmée de dépendances en aval n’a été signalée et aucune chaîne d’exploitation connue n’a été observée.

• Comme l’exécution du code nécessite une intervention manuelle et qu’aucune charge utile distante cachée n’a été identifiée, le risque reste faible pour la plupart des utilisateurs.

Comment la campagne IndonesianFoods s’est déroulée

Il ne s’agit pas d’un ver classique ni d’une exploitation à distance, mais plutôt d’un processus de publication automatisé : un script génère et publie des variantes d’un modèle de code d’application Web de base, probablement à des fins d’incitation ou d’expérimentation (par exemple, dans le cadre d’une promotion de cryptomonnaie liée à « tea.xyz »).

L’analyse a révélé que les packages ne contenaient aucune charge utile nuisible ; beaucoup comprenaient simplement du code passe-partout ou des stubs. Le processus de publication ne disposait pas de condition d’arrêt automatisée et semble avoir été déclenché manuellement certains jours, plutôt que de se propager de manière autonome via des systèmes infectés.

Récapitulatif de l’activité

• Utilisation d’un ou de plusieurs comptes NPM disposant de droits de publication étendus.

• Réutilisation d’un modèle de code pour créer des centaines ou des milliers de variantes.

• Packages peu téléchargés et très peu utilisés

• Pas de charges utiles furtives ou polymorphes complexes, mais des publications massives et bruyantes.

Pourquoi l’activité n’a-t-elle pas été détectée plus tôt ?

• Comme les packages étaient peu téléchargés et n’avaient aucun effet évident à l’exécution, ils sont passés inaperçus.

• Historiquement, les heuristiques des registres se sont concentrées sur les exploits et les comportements malveillants après l’installation, plutôt que sur le seul volume de publications.

• La campagne semble en partie abandonnée ; aucune exploitation active n’a été observée.

Stratégie de détection et d’analyse

Mesures pour les développeurs et les organisations

Les développeurs peuvent utiliser des outils comme la Snyk Vulnerability Database pour évaluer les nouvelles dépendances selon leur popularité, leur maintenance, leur sécurité et des indicateurs liés à la communauté. 

Il est également important de veiller à ce que les analyses automatisées couvrent à la fois l’état des dépendances et les risques liés au code, à l’aide d’outils tels que :

• Snyk Open Source (analyse de la composition logicielle) analyse les bibliothèques tierces à la recherche de vulnérabilités connues et de problèmes de licence. 

• Snyk Code (analyse statique de la sécurité des applications) détecte les vulnérabilités dans le code personnalisé.

• Snyk Container et Snyk IaC analysent respectivement les images de conteneurs et les configurations d’infrastructure as code.

Dans le contexte de cet incident, vous pouvez signaler les packages ayant très peu de téléchargements ou dont le contenu se répète sur de nombreuses versions. Il est également utile de surveiller les téléversements soudains à grande échelle provenant d’un même compte ou la réutilisation de modèles entre packages. Enfin, exploitez les heuristiques liées aux métadonnées, comme la date de dernière publication, l’historique des versions, le nombre de responsables de maintenance et l’activité de la communauté.

Comment les équipes responsables des registres peuvent améliorer la surveillance

La surveillance peut être améliorée en suivant les schémas de publication en masse, notamment le volume et les horaires de publication par compte. Il est également important de détecter les pics du nombre de publications, les changements fréquents de versions et la réutilisation de schémas de nommage. Les équipes des registres devraient intégrer des contrôles de réutilisation des modèles, par exemple en comparant les empreintes des fichiers de différents packages. Enfin, elles devraient évaluer dès le début des indicateurs de « santé » des métadonnées, comme le nombre de téléchargements, les étoiles du dépôt et l’activité des responsables de maintenance.

Atténuation des risques et prochaines étapes

Pour les utilisateurs finaux et les organisations :

1. Aucune mesure corrective immédiate n’est nécessaire si vous n’avez pas référencé ni installé l’un des packages suspects.

2. Examinez votre graphe de dépendances pour repérer les packages inutilisés ou à faible risque, puis supprimez ou isolez les dépendances rarement utilisées.

3. Utilisez Snyk Advisor avant l’installation : vérifiez l’état et les indicateurs de risque d’un package avant d’ajouter une nouvelle dépendance.

4. Utilisez npq : npq est un outil open source qui empêche l’installation de ce type de packages à l’aide d’heuristiques, comme le nombre de téléchargements. 

5. Définissez des contrôles de politique dans votre CI/CD : par exemple, bloquez l’ajout de packages dont le nombre de téléchargements est inférieur à un seuil donné ou qui n’ont pas fait l’objet de commits récents.

En conclusion

Bien que l’apparition de ces publications sur le registre NPM ait fait les gros titres en évoquant un « ver » ou une attaque contre la chaîne d’approvisionnement, notre enquête confirme qu’il ne s’agit pas d’une épidémie active de logiciels malveillants, mais des vestiges d’une ancienne automatisation liée à une campagne crypto. Le risque immédiat est faible pour la plupart des utilisateurs. 

Cet incident nous rappelle néanmoins qu’un package qui semble inoffensif peut présenter un risque pour la chaîne d’approvisionnement s’il n’est pas géré, s’il est mal entretenu ou s’il est obscur. Des outils comme Snyk Advisor et Snyk for JavaScript, des politiques de gestion des dépendances robustes et une surveillance efficace des registres contribuent à préserver l’hygiène de la chaîne d’approvisionnement dans l’ensemble des écosystèmes.