Bitwarden CLI piégé : Shai-Hulud infecte le gestionnaire

Ce qui s'est passé

Le 23 avril 2026, les équipes de Socket et d'Aikido ont identifié une version malveillante du package @bitwarden/cli diffusée sur le registre npm. Publiée le 22 avril, la version 2026.4.0 est restée téléchargeable entre 17 h 57 et 19 h 30 heure de l'Est américain, soit une fenêtre d'exposition d'environ une heure trente. Bitwarden a confirmé l'incident et rattaché cette compromission à l'attaque menée peu avant contre Checkmarx, dont les accès auraient permis de pivoter vers le pipeline de publication. L'affaire Bitwarden CLI Shai-Hulud illustre la persistance de ce ver auto-répliquant qui, depuis ses premières campagnes, siphonne jetons npm, clés cloud et secrets CI/CD avant de se propager aux paquets voisins. Un gestionnaire de mots de passe compromis, même brièvement, place les organisations concernées face à un risque de fuite majeur.

Le payload est une nouvelle itération du worm Shai-Hulud, déjà observé dans deux vagues précédentes en 2025. Baptisée « The Third Coming » par les analystes, cette variante vole les clés SSH, les secrets cloud AWS, GCP et Azure, les credentials d'outils de coding IA comme Cursor ou Copilot, et scanne les tokens npm de la victime pour injecter la backdoor dans d'autres packages qu'elle publie. Le vecteur de propagation transforme chaque développeur compromis en nouveau relais actif.

Selon Socket, la chaîne d'infection est liée à la campagne TeamPCP en cours, qui poursuit son offensive sur l'écosystème JavaScript depuis plusieurs semaines. Bitwarden a invalidé la version incriminée, déclenché une rotation complète de ses tokens de publication et demandé aux utilisateurs ayant installé la version piégée de révoquer immédiatement leurs clés SSH et secrets cloud exposés.

Pourquoi c'est important

L'attaque confirme l'enchaînement redouté des compromissions supply chain : un fournisseur de sécurité (Checkmarx) tombe, puis sert de tremplin pour atteindre un autre fournisseur de sécurité (Bitwarden), dans une cascade qui finit par toucher les développeurs finaux. Chaque maillon infecté devient à son tour un vecteur, ce qui rend le confinement exponentiellement plus complexe que pour une attaque isolée sur un seul éditeur.

Pour les équipes DevSecOps, l'épisode rappelle que les installations automatisées de CLI côté développeur ou côté CI/CD doivent passer par un registre privé avec verrouillage de version, et que les secrets présents sur les postes développeurs (SSH, cloud, tokens IA) doivent être rotés au moindre doute. La fenêtre de 1 h 30 suffit à infecter des milliers de runners CI qui auto-mettent à jour leurs dépendances.

Ce qu'il faut retenir

• Révoquez et rotez vos clés SSH, secrets cloud et tokens IA si vous avez installé @bitwarden/cli v2026.4.0 entre le 22 et le 23 avril 2026.
• Mettez en place un miroir npm privé avec scan SCA automatique pour toute nouvelle version publiée.
• Surveillez les publications npm sortantes depuis vos postes : un worm se propage en réutilisant les tokens locaux.

Le contexte : une chaîne de compromissions en cascade

Cet incident s'inscrit dans une escalade préoccupante des attaques supply chain visant l'écosystème npm depuis 2025. Shai-Hulud, du nom du ver des sables de l'univers Dune, n'en est pas à son coup d'essai : une première vague avait touché plus de 500 packages npm en septembre 2025, suivie d'une deuxième itération plus agressive en novembre. Cette « troisième venue » marque une évolution qualitative majeure : au lieu de cibler des packages obscurs à faible visibilité, les attaquants remontent la chaîne jusqu'à des éditeurs de sécurité eux-mêmes, transformant des outils censés protéger les développeurs en vecteurs d'infection. Le fait que Checkmarx, plateforme de test de sécurité applicative utilisée par des milliers d'entreprises pour auditer leur propre code, ait servi de point d'entrée illustre un paradoxe structurel : plus un fournisseur est profondément intégré dans les pipelines CI/CD de ses clients, plus sa compromission a un effet de levier destructeur.

Les chercheurs de Socket estiment que la campagne TeamPCP a already touché plusieurs dizaines de packages depuis son lancement, avec une méthodologie constante : exploitation d'un accès initial chez un fournisseur tiers, publication rapide d'une version piégée, fenêtre d'exposition volontairement courte pour limiter la détection automatisée, puis propagation via les identifiants npm volés aux victimes. Cette approche « hit-and-run » complique le travail des équipes de threat intelligence, qui doivent désormais surveiller en continu les registries de paquets plutôt que réagir a posteriori. Pour Bitwarden, dont le CLI est largement utilisé dans des scripts d'automatisation et des pipelines DevOps pour injecter des secrets à l'exécution, la compromission touche directement des environnements à privilèges élevés — un scénario que les experts qualifient de « pire cas » pour ce type d'outil.

Mesures de mitigation recommandées

• Vérifier immédiatement la version installée avec bw --version et comparer avec les releases officielles publiées sur le dépôt GitHub de Bitwarden.
• Auditer l'historique npm install et les logs CI/CD pour repérer toute installation de la version 2026.4.0 entre le 22 avril 17 h 57 et 19 h 30 (heure de l'Est).
• Régénérer intégralement les clés SSH, tokens npm, credentials cloud (AWS, GCP, Azure) et identifiants d'outils IA sur toute machine ayant exécuté le package compromis.
• Activer la vérification d'intégrité des packages (lockfiles signés, npm audit, outils comme Socket ou Aikido) sur les pipelines exposés aux dépendances tierces.
• Surveiller les publications sortantes des comptes npm des développeurs concernés, le ver injectant sa charge dans les packages qu'ils maintiennent eux-mêmes.