Pendant 93 minutes, l'installation du CLI « officiel » de Bitwarden a transformé des ordinateurs portables en Launchpad pour pirater des comptes GitHub

Le 22 avr., une version malveillante de l'interface de ligne de commande de Bitwarden est apparue sur npm sous le nom de package officiel @bitwarden/cli@2026.4.0. Pendant 93 minutes, quiconque a téléchargé le CLI via npm a reçu un substitut backdooré à l'outil légitime.

Bitwarden a détecté la compromission, supprimé le package et publié une déclaration indiquant qu'il n'avait trouvé aucune preuve que des attaquants avaient accédé aux données du coffre-fort des utilisateurs finaux ou compromis les systèmes de production.

La société de recherche en sécurité JFrog a analysé la charge utile malveillante et a constaté qu'elle ne s'intéressait pas particulièrement aux coffres-forts Bitwarden. Elle ciblait les tokens GitHub, les tokens npm, les clés SSH, l'historique du shell, les identifiants AWS, les identifiants GCP, les identifiants Azure, les secrets GitHub Actions et les fichiers de configuration des outils d'IA.

Ce sont des identifiants qui régissent la façon dont les équipes construisent, déploient et accèdent à leur infrastructure.

Bitwarden sert plus de 50 000 entreprises et 10 millions d'utilisateurs, et sa propre documentation décrit le CLI comme un moyen « puissant et complet » d'accéder au coffre-fort et de le gérer, notamment dans des workflows automatisés qui s'authentifient à l'aide de variables d'environnement.

Bitwarden répertorie npm comme la méthode d'installation la plus simple et la plus recommandée pour les utilisateurs déjà familiers avec le registre. Cette combinaison d'utilisation automatisée, d'installation sur machine de développeur et de distribution npm officielle place le CLI exactement là où les secrets d'infrastructure à haute valeur ont tendance à résider.

L'analyse de JFrog montre que le package malveillant a réorienté à la fois le hook de préinstallation et le point d'entrée du binaire bw vers un chargeur qui récupérait le runtime Bun et lançait une charge utile obfusquée. La compromission se déclenche au moment de l'installation et à l'exécution.

Une organisation pourrait exécuter le CLI backdooré sans toucher aucun mot de passe stocké, tandis que le malware collectait systématiquement les identifiants régissant ses pipelines CI, ses comptes cloud et son automatisation de déploiement.

La société de sécurité Socket affirme que l'attaque semble avoir exploité une GitHub Action compromise dans le pipeline CI/CD de Bitwarden, ce qui correspond à un schéma que les chercheurs de Checkmarx suivent.

Bitwarden a confirmé que l'incident est lié à la campagne plus large de la chaîne d'approvisionnement de Checkmarx.

Le goulot d'étranglement de la confiance

Npm a construit son modèle de publication de confiance pour répondre précisément à cette catégorie de risques.

En remplaçant les tokens de publication npm de longue durée par une authentification CI/CD basée sur OIDC, le système supprime l'un des chemins les plus courants utilisés par les attaquants pour détourner les publications de registres, et npm recommande la publication de confiance et la considère comme une avancée significative.

La surface plus difficile est la logique de publication elle-même, telle que les workflows et les actions qui invoquent l'étape de publication. La documentation propre de npm recommande des contrôles au-delà d'OIDC, tels que des environnements de déploiement avec des exigences d'approbation manuelle, des règles de protection des tags et des restrictions de branches.

Les paramètres d'environnement de GitHub permettent aux organisations d'exiger la validation des réviseurs avant qu'un workflow puisse se déployer. Le framework SLSA va plus loin en demandant aux consommateurs de vérifier que la provenance correspond aux paramètres attendus, tels que le dépôt correct, la branche, le tag, le workflow et la configuration de build.

L'incident Bitwarden montre que le problème plus difficile se situe au niveau de la couche de workflow. Si un attaquant peut exploiter le workflow de publication lui-même, le badge « officiel » accompagne toujours le package malveillant.

La publication de confiance transfère la charge de confiance vers l'intégrité des workflows et des actions qui l'invoquent, une couche que les organisations ont largement laissée non examinée.

Un token pour de nombreuses portes

Pour les équipes de développement et d'infrastructure, un workflow de publication compromis expose les pipelines CI, l'infrastructure d'automatisation et les identifiants qui les régissent.

L'analyse de JFrog montre qu'une fois que le malware a obtenu un token GitHub, il pouvait valider le token, énumérer les dépôts accessibles en écriture, lister les secrets GitHub Actions, créer une branche, valider un workflow, attendre son exécution, télécharger les artefacts résultants, puis nettoyer.

L'obtention du token crée une chaîne automatisée qui transforme un seul identifiant volé en accès persistant à travers l'infrastructure d'automatisation d'une organisation.

L'ordinateur portable d'un développeur qui installe un package officiel empoisonné devient un pont entre le magasin d'identifiants local de l'hôte et l'accès GitHub à tout ce que ce token GitHub peut atteindre.

L'incident Bybit est une analogie structurelle étroite. Un poste de travail de développeur compromis a permis aux attaquants d'empoisonner une interface amont de confiance, qui a ensuite atteint le processus opérationnel de la victime.

La différence est que Bybit impliquait une interface web Safe altérée, tandis que Bitwarden impliquait un package npm officiel altéré.

Dans les environnements Crypto, fintech ou de garde, ce chemin peut aller d'un magasin d'identifiants aux signataires de publication, à l'accès cloud et aux systèmes de déploiement sans jamais toucher une entrée de coffre-fort.

En 60 jours, Checkmarx a divulgué des workflows GitHub Actions compromis et des plugins OpenVSX, tandis que la Cloud Security Alliance a averti que la campagne TeamPCP compromettait activement des projets open-source et des composants d'automatisation CI/CD.

JFrog a documenté comment une GitHub Action Trivy compromise a exfiltré le token de publication de LiteLLM et a permis des publications PyPI malveillantes, et Axios a divulgué que deux versions npm malveillantes ont circulé pendant environ trois heures via un compte de mainteneur compromis.

Sonatype a compté plus de 454 600 nouveaux packages malveillants en 2025 seulement, portant le total cumulé à plus de 1,2 million. Bitwarden s'inscrit dans une chaîne d'incidents qui confirme les workflows de publication et les registres de packages comme la principale surface d'attaque.

La cause première précise n'est pas encore publique, car Bitwarden a confirmé un lien avec la campagne Checkmarx mais n'a pas publié une analyse détaillée de la façon dont l'attaquant a obtenu l'accès au pipeline de publication.

Les résultats de l'attaque

Le résultat le plus fort pour les défenseurs est que cet incident accélère une redéfinition de ce que signifie « officiel ».

Aujourd'hui, la publication de confiance attache des données de provenance à chaque package publié, confirmant ainsi l'identité de l'éditeur dans le registre. SLSA documente explicitement un standard plus élevé pour que les vérificateurs vérifient si la provenance correspond au dépôt attendu, à la branche, au workflow et aux paramètres de build.

Si ce standard devient le comportement par défaut des consommateurs, « officiel » commence à signifier « construit par le bon workflow sous les bonnes contraintes », et un attaquant qui compromet une action mais ne peut pas satisfaire toutes les contraintes de provenance produit un package que les consommateurs automatisés rejettent avant qu'il n'arrive.

Le chemin à court terme le plus plausible va dans la direction opposée. Les attaquants ont démontré à travers au moins 4 incidents en 60 jours que les workflows de publication, les dépendances d'actions et les identifiants adjacents aux mainteneurs donnent des résultats à haute valeur avec relativement peu de friction.

Chaque incident successif ajoute une autre technique documentée à un manuel public de compromission d'actions, de vol de tokens depuis la sortie CI, de détournement de compte de mainteneur et d'abus du chemin de publication de confiance.

À moins que la vérification de provenance ne devienne le comportement par défaut des consommateurs plutôt qu'une couche de politique optionnelle, les noms de packages officiels commanderont plus de confiance que leurs processus de publication ne peuvent justifier.

The post For 93 minutes, installing Bitwarden's 'official' CLI turned laptops into launchpads for hijacking GitHub accounts appeared first on CryptoSlate.