Le 8 octobre 2026, le paquet npm tensorlake, utilisé par des développeurs intégrant de l'IA dans leurs applications, a été compromis dans le cadre d'une campagne baptisée ChainDrop / Shai-Hulud. La version piégée volait des jetons npm et GitHub, des identifiants AWS et Kubernetes, des clés SSH, et même les fichiers de configuration d'outils IA comme Claude (SC World). Ce n'est pas un cas isolé : c'est le symptôme d'une menace qui touche directement les sites, ERP et logiciels construits avec des briques open source — c'est-à-dire la quasi-totalité des projets web actuels.

Une industrialisation des attaques sur les dépendances

Les chiffres donnent le vertige. Un suivi mené sur deux ans recense 59 campagnes et 657 paquets malveillants indexés entre juin 2024 et juin 2026, avec un seul mois de mai 2026 totalisant 14 campagnes et 346 paquets touchés (Phoenix Security). L'écosystème npm, utilisé par la majorité des sites web, applications et logiciels SaaS modernes, concentre à lui seul près de 90 % des logiciels malveillants open source détectés, et les attaques ont bondi de 188 % en un an sur la seule plateforme Sonatype (Phoenix Security).

Le vers Shai-Hulud, qui a donné son nom à plusieurs de ces campagnes, s'est propagé de façon autonome à travers 800 paquets npm en volant un jeton pour en compromettre d'autres, dans un effet domino difficile à stopper une fois lancé (Group-IB). Autre exemple documenté : en mai 2026, plusieurs versions du paquet node-ipc, largement utilisé dans l'écosystème Node.js, contenaient une charge malveillante capable de siphonner plus de 90 catégories d'identifiants avant de les exfiltrer vers un serveur maquillé en infrastructure Azure (StepSecurity).

Comment ça marche, en langage simple

Un développeur n'écrit jamais tout son code à zéro : une application web, un module métier ou une boutique en ligne s'appuie sur des centaines de "briques" toutes faites, publiées sur des registres comme npm ou Composer, maintenues par des bénévoles ou de petites équipes. Une attaque de la chaîne de dépendances consiste à s'infiltrer dans l'une de ces briques — en piratant le compte d'un mainteneur, par exemple — pour y glisser du code malveillant. Résultat : chaque entreprise qui installe cette brique, même sans le savoir, installe aussi le piège.

Le point commun des cas récents est la cible : les secrets techniques (clés d'accès cloud, jetons GitHub, identifiants de base de données, clés SSH) plutôt que les données finales. Une fois ces clés volées, l'attaquant peut rebondir vers l'infrastructure complète d'une entreprise, bien au-delà du simple site touché.

Votre WooCommerce, votre Dolibarr ou votre SaaS sont-ils concernés ?

Oui, indirectement, dès que votre projet a été construit ou est maintenu avec des outils modernes : un thème ou un plugin WordPress/WooCommerce, un module Dolibarr développé avec des outils JavaScript, ou un logiciel SaaS bâti sur une stack Node.js s'appuient tous, à un moment ou un autre, sur des dépendances tierces. Le risque n'est pas que "votre code" soit malveillant, mais qu'une brique externe, mise à jour automatiquement, le devienne du jour au lendemain.

C'est pour cette raison que la vigilance ne peut pas reposer uniquement sur l'outil : elle dépend de la rigueur du partenaire qui développe et maintient votre développement web sur mesure, vos plugins WooCommerce ou vos modules Dolibarr.

Les bons réflexes, sans devenir expert en cybersécurité

  • Figer les versions des dépendances (fichiers de verrouillage type lockfile) plutôt que de tout mettre à jour automatiquement en production.
  • Limiter les droits des jetons et clés utilisés en intégration continue : un jeton ne devrait jamais avoir plus d'accès que nécessaire.
  • Séparer les environnements de développement, de test et de production, pour qu'une compromission locale ne contamine pas directement le site en ligne.
  • Auditer les mises à jour avant déploiement, en particulier sur les dépendances les plus sensibles (paiement, authentification, envoi d'e-mails).
  • Documenter et versionner les scripts d'intégration, de déploiement ou d'automatisation des tâches pour repérer rapidement toute modification suspecte.

S'appuyer sur un partenaire qui connaît sa stack

Ce niveau de vigilance demande du temps et une veille technique continue, difficilement tenable en interne pour une PME sans équipe dédiée. C'est le rôle d'un partenaire de développement de surveiller les dépendances utilisées sur vos projets, de figer les versions critiques et de réagir rapidement en cas d'alerte sur une bibliothèque que vous utilisez. Découvrez nos expertises développement et la façon dont nous intégrons cette vigilance dans chaque projet, qu'il s'agisse d'un site, d'un ERP ou d'un logiciel SaaS.

En résumé

Les attaques sur la chaîne de dépendances ne sont plus marginales : elles touchent l'écosystème dont dépend la quasi-totalité du web professionnel. Vous n'avez pas besoin de tout maîtriser techniquement, mais vous devez savoir qui, chez votre prestataire ou dans votre équipe, surveille ces dépendances. Si ce point n'est pas clair pour votre site, votre ERP ou votre SaaS, c'est le bon moment pour en discuter : contactez-nous pour un échange sur la sécurisation de votre stack technique.

Questions fréquentes

C'est une attaque qui ne vise pas directement votre site ou votre logiciel, mais l'une des bibliothèques open source qu'il utilise en coulisses. En piratant un paquet largement réutilisé (sur npm par exemple), l'attaquant touche d'un coup toutes les applications qui l'installent, sans avoir eu besoin de pirater chacune individuellement.

Potentiellement, dès que des outils de développement modernes basés sur npm ou des gestionnaires de dépendances similaires interviennent dans leur construction ou leur maintenance. Le risque dépend surtout de la rigueur avec laquelle les mises à jour de dépendances sont contrôlées avant d'être déployées sur votre site en production.

Il faut comparer la liste exacte des versions installées (via le fichier de verrouillage du projet) avec les listes de paquets compromis publiées par les éditeurs de sécurité, puis vérifier les journaux d'accès et les jetons utilisés en intégration continue. C'est un travail technique récurrent, qu'il vaut mieux confier à l'équipe qui maintient votre application plutôt que de le découvrir après coup.