La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets
Dominos
Illustration : Flock
Le 23 avril à 18h36
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.
La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets
Dominos
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.
Sécurité
Sécurité
5 min
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)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 23 avril à 18h54
Le 23 avril à 19h24
Le 23 avril à 19h51
Le 24 avril à 08h04
Le 24 avril à 10h54
Le 23 avril à 19h47
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)...
Modifié le 23 avril à 20h08
Le 23 avril à 20h31
Le 23 avril à 20h56
Le 24 avril à 07h23
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.
Le 24 avril à 08h06
Le 24 avril à 08h34
Le 24 avril à 09h31
Le 24 avril à 10h20
Le 24 avril à 10h29
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.
Le 24 avril à 10h33
Le 24 avril à 11h21
C'est l'intérêt des firewall niveau 7 qui permettent le whitelisting d'URLs.
Le 24 avril à 08h22
Le 24 avril à 22h53
Le 26 avril à 11h05
Le 27 avril à 11h54
Le 27 avril à 12h24
Le 29 avril à 07h14
Le 29 avril à 08h14
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.
Le 29 avril à 18h47
Le 29 avril à 22h00
Le 24 avril à 09h41
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
Le 29 avril à 07h11
Le 24 avril à 13h17
Comment protéger ces informations alors ?
Le 24 avril à 16h12
Modifié le 24 avril à 23h25
Le 25 avril à 09h43
Le 25 avril à 13h40
Mais là il n'y a aucun risque que ça arrive.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?