Connexion Premium

La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets

Dominos

La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets

Illustration : Flock

Le paquet NPM du CLI de Bitwarden publié comme la version 2026.4.0 est en fait un malware qui récupère les secrets, clés SSH et autres identifiants. Cette version a été rapidement étiquetée comme « obsolète » et l’équipe du projet a contacté NPM pour que le paquet soit retiré au plus vite.

Dans la série des attaques de la supply chain, on continue. Après Trivy, LiteLLM, Axios et hier Xinference, on ajoute aujourd’hui le client en ligne de commande du gestionnaire de mots de passe Bitwarden. Cette fois, c’est le paquet NPM (Node Package Manager) du CLI qui a été visé avec l’utilisation du numéro de version 2026.4.0, la légitime dernière version 2026.3.0 ayant été publiée il y a trois semaines.

L’alerte vient de l’équipe de l’entreprise de sécurité JFrog. Prévenue par un utilisateur, l’équipe de Bitwarden a répondu avoir bien constaté le problème : « Nous avons depuis étiqueté comme « obsolète » cette version et contacté NPM pour qu’elle soit supprimée ». Aucun autre paquet ou application/extension de Bitwarden ne semble compromis, pas plus que les coffres-forts des utilisateurs.

De fait, expliquent les chercheurs de JFrog, le paquet vérolé utilise les mêmes métadonnées dans le fichier build/bw.js que la 2026.3.0 du paquet, mais elle renvoie le fichier preinstall et le binaire bw vers un script bw_setup.js. Celui-ci vérifie d’abord si l’environnement d’exécution JavaScript Bun est installé et en récupère une version si ce n’est pas le cas.

Encore une récupération des secrets, avec un traitement spécial pour GitHub

Suite à ça, le paquet verolé peut lancer l’attaque via l’exécution du fichier bw1.js. Celui-ci cible des fichiers de configuration utilisés par les développeurs pour stocker des informations comme les clés SSH, les identifiants Git, NPM, AWS, Google Cloud Platform, ou encore les fichiers de configuration de l’IA Claude ou de celle de Kiro.

Concernant GitHub, le paquet pirate va plus loin. D’abord, il vérifie que les identifiants sont bons via https://api.github.com/user. Ensuite, il va essayer d’extraire davantage d’informations confidentielles hébergées sur GitHub.

Concernant l’exfiltration, le paquet vérolé a deux méthodes possibles. Soit il exfiltre les données via une requête POST après les avoir sérialisées dans un JSON, compressées et chiffrées. Si cette méthode ne fonctionne pas, il peut utiliser GitHub pour stocker dans un nouveau dépôt les blobs JSON des données récupérées.

Pour celles et ceux qui auraient installé cette fausse version 2026.4.0 du CLI de Bitwarden, il faut partir du principe que les identifiants des outils cités ci-dessus sont compromis, explique JFrog. Il faut donc d’abord désinstaller le paquet NPM @bitwarden/cli et renouveler les secrets susceptibles d’avoir été compromis. Voici les commande proposées (la dernière permet d’empêcher l’exécution automatique de scripts à l’installation de paquets) :

npm uninstall -g @bitwarden/cli
npm cache clean --force
npm config set ignore-scripts true

Pour chercher des traces du piratage et du téléchargement de Bun, voici deux commandes proposées par Jfrog. Si vous avez des résultats, alors inquiétez-vous.

rg -n "audit\\.checkmarx\\.cx|LongLiveTheResistanceAgainstMachines|beautifulcastle" .
ls -la bun bun.exe bw1.js bw_setup.js 2>/dev/null

Encore TeamPCP ?

Dans le titre de son billet sur cette attaque, JFrog l’attribue rapidement au groupe de pirates TeamPCP qui serait aussi responsable de celle contre Xinference. Mais son équipe ne donne aucune information qui pourrait permettre d’identifier le groupe. Sur X, le compte « officiel » de TeamPCP a été suspendu.

De son côté, Socket estime que « ce paquet a été compromis lors de ce qui semble être une nouvelle attaque de TeamPCP ». « L’attaque semble avoir exploité une action GitHub compromise dans le pipeline CI/CD de Bitwarden, ce qui correspond au schéma observé dans d’autres dépôts touchés par cette campagne », explique d’ailleurs Socket qui ajoute que cette attaque se place dans la continuité de celle que l’entreprise a découverte hier sur la supply chain Checkmarx de KICS.

Dans un message, l’équipe de Bitwarden a confirmé avoir identifié que cette version vérolée du paquet a été distribuée pendant environ 1h30 ce mercredi 22 avril et qu’elle se situait « dans le cadre d’un incident plus général affectant la supply chain de Checkmarx ».

Elle explique que son enquête « n’a révélé aucun élément indiquant que les données du coffre-fort des utilisateurs finaux aient été consultées ou aient été exposées à un risque, ni que les données ou les systèmes de production aient été compromis. Dès que le problème a été détecté, les accès compromis ont été révoqués, la version malveillante de npm a été retirée, et des mesures correctives ont été immédiatement mises en œuvre ».

« Bitwarden a mené à bien un examen de ses environnements internes, de ses processus de déploiement et des systèmes associés, et aucun autre produit ou environnement affecté n’a été identifié à ce stade. Un CVE concernant la version 2026.4.0 de Bitwarden CLI est en cours d’émission dans le cadre de cet incident », ajoute l’équipe.

Commentaires (33)

votre avatar
Je vais crois que je vais continuer encore quelques temps à utiliser mes mots de passes générés à la main finalement.
votre avatar
Un bon vieux KeePass(XC) avec un kdbx auto-hébergé et un fichier clé stocké exclusivement en local, il n'y a rien de tel !
votre avatar
je reconnais avoir fait cela pendant TRES longtemps mais j'ai voulu m'amusé avec les VPS et apprendre des trucs, mais au final factuellement Bitwarden n'apporte pas grand chose de plus je reconnais (peut etre le fait de gérer les passwds par compte et de pouvoir se les partager ensuite)
votre avatar
Pareil :)
votre avatar
Rant: Ca serait juste sympatique qu'un jour le portage vers qt6 soit réellement pris au sérieux car ça fait quand même 5 ans que qt5 est eol. Les distribs commencent fortement à le poussé dehors à cause de ça..
votre avatar
Oh le coup chaud...
après avoir passer les 2 à 3 derniers jours (oui je suis doué...) a suivre le tuto VPs pour install bit(vault)warden j'ai eu un peu peur à la lecture de l'article....
mais bon de ce que j'ai compris c'est le composant vaultwarden que j'ai installé(qui est un fork) et le client bitwarden est récupéré sur le site donc pas concerné (enfin j'espère)...
votre avatar
ça ne concerne pas les clients finaux si j'ai bien compris
votre avatar
Rien que le fait de voir des CLI en Node m'hérisse le poil, à titre perso.
votre avatar
Conclusion, un environnement virtualisé pour le développement, saylebien.
votre avatar
Suis pas trop sûr de ça...

Si tu as un environnement de dev virtualisé, à moins de cas très particuliers, il aura accès à tes identifiants cloud et autres clés ssh pour faire les déploiements. Une librairie vérolée pourra donc les exfiltrer.
votre avatar
Après l'erreur c'est d'utiliser la latest...
votre avatar
Mais qui parfois sert à corriger des grosses failles. Pas facile du coup. Mais effectivement, en ce moment, dur de se dire que la dernière version du logiciel (quelqu'il soit) mis à jour est saine.
votre avatar
l'erreur c'est d'utiliser la latest
Mais parfois la latest est obtenue via une longue chaîne d'indirection qu'on ne maîtrise pas nécessairement. Y'a pas 36 solutions, il faut que d'une manière ou d'une autre, le gestionnaire de paquets lui-même ait les fonctionnalités d'un antivirus, vérification d'intégrité, ne pas laisser passer les packages trop récents, etc. À force de marteler qu'on n'a pas besoin d'antivirus sous Mac / Linux on a fini par le croire, mais la définition de virus a bien changé depuis que npm et pip (et ce qui en tient lieu pour go, rust et autres php) sont devenus également des vecteurs d'installation de logiciels tout faits.
votre avatar
C'est un problème de chaîne confiance et en ce moment, il vaut mieux être parano.
votre avatar
C'est tout l'intérêt du SCA et de l'analyse sécurité dès le poste de dev.

Bon, le problème, c'est que ce genre de faille se découvre après coup. Vu les avancées en matière d'analyse de code par IA, possible que le contrôle des dépendances gagne en robustesse en détectant les fuites de données plus en amont. Mais derrière, les attaquants se cacheront encore plus.

L'éternel jeu du chat et de la souris.

Raison pour laquelle la sécurisation passe aussi par l'analyse des entrées et sorties réseau du poste de dev. Si un package fait des requêtes vers des URL / IP inconnues et non approuvées, ça doit lever une alerte.
votre avatar
l'analyse des entrées et sorties réseau du poste de dev
Je suis évidemment d'accord avec tout ça, mais les gestionnaires npm et pip ont depuis bien longtemps débordé du cadre de la station de dev, et servent désormais d'installateurs pour toute une flopée d'utilitaires généralistes. Un gestionnaire de pots de masse, ce n'est pas réservé aux postes dev...
votre avatar
C'est la même chose pour l'étape de build, déploiement et run : les entrées et sorties de la workload doivent être restreintes au strict nécessaire. Un container ne doit pas pouvoir aller taper des URLs sur la Terre entière sans raisons !

C'est l'intérêt des firewall niveau 7 qui permettent le whitelisting d'URLs.
votre avatar
Non, c'est un environnement maîtrisé du point de vue réseau qui est nécessaire ici. Un env virtualisé avec autant de droits que le poste normal sera tout aussi vulnérable.
votre avatar
Les deux sont nécessaires. La virtualisation par projet pour isoler complètement l'environnement et éviter que tout logiciel vérolé ne vienne piquer des données, et évidemment, une configuration réseau au poil.
votre avatar
En effet, un mix des deux et ce, sur toute la chaîne de production du logiciel. (et au runtime, évidemment)
votre avatar
Reste un problème de taille... Même face à tout ça, proposer une version publique potentiellement contaminée, sans qu'on s'en aperçoive...
votre avatar
Oui. La supply chain est toujours à risques. Mais les actions citées sont aussi là pour les réduire.
votre avatar
La virtualisation ne protège de rien du tout ! l'env infecté quel qu'il soit a besoin des clés d'API et autre secrets récoltés ici
votre avatar
La virtualisation protège en limitant les données accessibles à celles strictement nécessaires au projet sur lequel tu es.

Sans la virtualisation, c'est openbar sur tout le PC : les cookies de ton navigateur, tes wallets (si tu en as), les scan de pièces d'identité (pour l'usurpation, c'est top), l'envoi de mail en ton nom, etc.
votre avatar
Oui, sauf que ce n'est absolument pas le cas de la faille en question. Pour cette faille particulière la virtualisation n'apporte rien, voire pire multiplie les risques (chaque env mutualisé doit être contrôlé voire nettoyé individuellement); à l'ancienne (sans virtualisation, docker ou autre) un simple "-g" sur chaque commande npm et tu fixes l'ensemble de tes projets node.js.
votre avatar
Oui, sauf que ce n'est absolument pas le cas de la faille en question
Pourquoi ? Ce qui est ciblé c'est tous les identifiants github, aws, clé ssh, etc. Avoir des environnements séparés par projet permet d'éviter que la corruption d'un projet ne fasse fuiter les info de potentiellement tous les projets présents sur la machine.
votre avatar
J'ai viré NodeJs NPM de mon poste de travail la semaine dernière...
J'ai perdu du confort (principalement le linter JS et playwright-cli)....
Je ne suis pas assez spécialiste pour juger de ce que est secure ou pas et j'ai conclu que cette stack était clairement trop dangereuse pour ce qu'elle m'apportait
votre avatar
HS il faut lire l'article, avant de commenter
votre avatar
informations comme les clés SSH, les identifiants Git, NPM, AWS, Google Cloud Platform, ou encore les fichiers de configuration de l’IA Claude ou de celle de Kiro
Comment protéger ces informations alors ?
votre avatar
En n'installant pas n'importe quoi sur sa machine ?
votre avatar
Et en confinant strictement chaque projet au sein d'un environnement dédié, ne contenant rien d'autre, et avec un pare-feu convenablement paramétré, laissant passer sur liste blanche uniquement.
votre avatar
Les clés SSH elles peuvent stockés dans proton pass, 1Password et Bitwarden; c'est ça de moins accessible
votre avatar
Il n'est pas certain que les stocker dans Bitwarden va les protéger contre une exfiltration par une version vérolée de Bitwarden CLI... Mais une clé SSH ça peut aussi se stocker chiffré. Il faudrait que ce soit SSH lui même qui soit vérolé pour les exfiltrer.

Mais là il n'y a aucun risque que ça arrive. :troll: :troll: :troll: