Une dépendance npm banale peut maintenant lancer du code avant même que ton application démarre. Le 4 août 2026, la version 6.0.0 de keyv, un module de stockage utilisé par des milliers de projets JavaScript, a été publiée avec un script d’installation malveillant. Snyk a retrouvé le même chargement dans onze versions de keyv, cacheable et de paquets proches. Si tu utilises Node.js, le sujet n’est pas réservé aux équipes sécurité : une installation suffit à ouvrir la porte aux droits de ton poste ou de ta chaîne d’intégration continue.
Le problème est d’autant plus piégeux que la bibliothèque continue de ressembler à une bibliothèque normale. Le code applicatif principal peut fonctionner, tandis qu’un script npm séparé s’exécute discrètement pendant l’installation. Le bon réflexe n’est donc pas de paniquer devant chaque mise à jour, mais de vérifier les versions réellement installées et les secrets accessibles au processus.
Une mise à jour qui transforme npm en lanceur de code
Snyk identifie keyv@6.0.0 comme version principale touchée. L’analyse a aussi relevé des versions compromises de cacheable, @cacheable/net, @cacheable/node-cache, flat-cache, file-entry-cache, cacheable-request, cache-manager, @cacheable/memory, @cacheable/utils et ecto. Le registre affichait encore plusieurs versions infectées sous l’étiquette latest au moment de l’enquête : dans un incident en cours, les listes et les étiquettes peuvent changer rapidement.
Le mécanisme est simple à comprendre. Le fichier package.json ajoute un script preinstall qui appelle setup.mjs, puis ce chargeur lance un second fichier beaucoup plus volumineux. Tu n’as pas besoin d’importer keyv dans ton code ni de démarrer ton service : la résolution et l’installation de la dépendance déclenchent déjà le script. Des fichiers de configuration ajoutés au dépôt ouvrent aussi un chemin possible via Claude Code ou VS Code, selon la confiance accordée à l’espace de travail.
Illustration : Snyk, « Inside the keyv npm Compromise », https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/
Pourquoi une dépendance de cache peut toucher tes secrets
Le risque vient des permissions du processus d’installation. Sur un poste de développement, le paquet peut voir les fichiers et variables auxquels Node.js a accès. Dans une chaîne CI, cela peut inclure des jetons GitHub, npm, cloud, Kubernetes, Vault ou des clés privées. Snyk attribue à des analyses indépendantes la description de la seconde étape et de sa persistance ; l’article précise ne pas avoir exécuté le code malveillant lui-même. Cette nuance est importante : on sépare ce qui a été observé dans les fichiers de ce qui vient d’une analyse externe.
Le fait que la version conserve le comportement attendu rend la détection plus difficile. Snyk a comparé keyv@6.0.0 à sa version candidate et indique que le contenu de dist/ reste identique, tandis que le manifeste et deux fichiers supplémentaires changent. Une bibliothèque qui fonctionne normalement n’est donc pas une preuve de propreté. Les scripts de cycle de vie et les fichiers ajoutés au paquet méritent leur propre contrôle.
Ce qu’il faut faire si ton projet est concerné
Commence par vérifier le fichier de verrouillage et l’arbre complet des dépendances, pas seulement package.json. Recherche keyv@6.0.0, les versions touchées de cacheable et les autres noms listés par Snyk. Ne réinstalle pas machinalement le paquet pour « voir » : l’installation est précisément le déclencheur. Utilise une machine isolée ou un environnement déjà considéré comme exposé pour l’analyse, puis conserve les journaux et les métadonnées du registre.
Snyk recommande de revenir à une version saine connue, notamment keyv@5.6.0 dans son instantané, après validation de la compatibilité. Reconstruis ensuite le verrouillage sans scripts, supprime node_modules et effectue une installation avec les scripts désactivés lorsque ton projet le permet. Cette option casse certains paquets légitimes : elle doit être appliquée avec une liste d’exceptions documentée, pas comme une formule magique.
Si une version compromise a tourné sur un poste ou un exécuteur, traite la machine comme potentiellement exposée. Isole-la, cherche les processus et fichiers inhabituels, puis fais tourner depuis un système propre tous les secrets accessibles au job : jetons de registre, clés cloud, identifiants de dépôt et accès aux bases. La révocation seule ne suffit pas si un mécanisme de persistance est encore actif.
Les protections arrivent, mais elles ne remplacent pas la prudence
GitHub a annoncé l’analyse automatique des paquets au moment de leur publication, avec publication normale, retenue pour revue ou blocage selon le résultat. La plateforme renforce aussi les alertes Dependabot sur les paquets malveillants et recommande le trusted publishing par OIDC ou la publication progressive avec validation à deux facteurs. Ces contrôles réduisent la fenêtre d’attaque, mais ils ne garantissent pas qu’un paquet déjà publié est inoffensif.
Pour les équipes, la combinaison utile est assez terre-à-terre : fichiers de verrouillage examinés, versions récentes laissées mûrir avant adoption, scripts d’installation limités, permissions CI minimales et rotation des secrets au moindre doute. Une dépendance n’est pas fiable parce qu’elle porte un nom connu, possède beaucoup de téléchargements ou affiche une signature valide. Dans npm, le colis peut être authentique et quand même contenir une très mauvaise surprise.
Sources
Snyk, « Inside the keyv npm Compromise: preinstall Malware, Trusted Provenance, and IDE Hooks », 4 août 2026 : https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/
npm, fiche officielle de keyv et historique de publication : https://www.npmjs.com/package/keyv
GitHub Changelog, analyse npm à la publication et métadonnées pour les paquets à double usage : https://github.blog/changelog/2026-08-04-npm-publish-time-malware-scanning-and-dual-use-metadata/
GitHub, « Disrupting supply chain attacks on npm and GitHub Actions » : https://github.blog/security/supply-chain-security/disrupting-supply-chain-attacks-on-npm-and-github-actions/
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet