Attaque en chaîne d’approvisionnement de Bitwarden CLI : audit du hook npm

8 min. de lecture

Le soir du 22 avril, un paquet malicieux de Bitwarden-CLI a été présent dans le npm-Registry pendant 93 minutes, livré via la distribution officielle de Bitwarden. Le code malveillant a été exécuté dans le hook de pré-installation et a extrait des jetons GitHub, des clés SSH, des fichiers .env et des secrets de cloud vers une subdomain audit.checkmarx.cx. Le véritable problème n’est pas le paquet capturé. Le véritable problème est que les équipes de sécurité DACH n’auront pas encore effectué une inventaire de leurs hooks de pré-installation en 2026.

Qu’est-ce qu’un hook de pré-installation ?

Qu’est-ce qu’un hook de pré-installation ? Un hook de pré-installation est un script qui est automatiquement exécuté par le gestionnaire de paquets npm avant l’installation ou l’utilisation du paquet en question. Il est défini dans le champ scripts.preinstall de la package.json. Le hook a les mêmes droits que le processus de build en cours et peut lire n’importe quelle file, établir des connexions réseau et exfiltrer des données. Il a été initialement conçu pour exécuter des étapes de build natives (par exemple, la compilation d’extensions C) avant le processus de configuration du paquet. En pratique, il est le vecteur d’exécution de code le plus courant dans les attaques de la chaîne d’approvisionnement npm, car il s’exécute sans aucune action de l’utilisateur.

Les types de hooks associés sont install (pendant l’installation), postinstall (après) et prepare (lors du git clone dans les dépendances). Tous les trois ont les mêmes droits et les mêmes types de risques. Un inventaire complet des hooks doit couvrir les quatre.

Qu’est-ce qui s’est passé, dans l’ordre

Le scénario de préinstallation de Bitwarden-CLI a eu un chronologie clairement documentée. Le Bitwarden Security Team a reconstruit le paquet infecté avec des minutes précises dans le forum communautaire Bitwarden officiel.

Le fenêtre de 93 minutes peut paraître petite, mais dans le contexte npm, elle est suffisamment grande pour affecter des milliers de builds automatisées. Toute pipeline CI qui a lancé un nouveau conteneur et installé @bitwarden/cli dans cette période a exécuté le hook de préinstallation. L’exfiltration s’est déroulée sans journalisation visible dans le flux de sortie npm par défaut.

Pourquoi les hooks de préinstallation sont les véritables problèmes

La réaction usuelle à un incident npm consiste à supprimer le package du Lockfile, le réinstaller et continuer à travailler. Cela soulage le symptôme, mais ne résout pas le mécanisme. Le mécanisme en question est la fonctionnalité de script de préinstallation de npm, qui exécute un script avant que le package ne soit utilisé de quelque manière que ce soit lors de l’installation. Dans le scénario Bitwarden, aucun utilisateur n’a activement appelé le CLI-Tool pour déclencher l’exfiltration. Il suffit d’avoir fait npm install.

La plupart des équipes d’ingénierie ne peuvent pas dire combien de leurs dépendances directes ont un hook de préinstallation. Les dépendances transitives sont encore plus préjudiciables. Un projet Node.js standard avec cinq cents dépendances transitives a généralement entre dix et quarante packages avec des hooks de préinstallation, install ou postinstall. Chacun de ces hooks est un vecteur d’exécution de code, où le temps de révision est nul. L’attaque Axios-npm avait le même mécanisme, mais avec un autre compte de maintainer comme point d’entrée.

Audit de quatre étapes pour les hooks de préinstall npm

Les équipes Sec peuvent commencer à inventorier leurs hooks lors d’un jour de formation. Quatre étapes suffisent pour un aperçu initial qui peut être utilisé immédiatement comme base de détection.

Étape 1: Inventorier tous les scripts de préinstall, d’install et de postinstall à travers tous les référentiels. L’outil standard est npm-audit-resolver ou un script simple qui parse chaque package.json dans les référentiels dev et les Lockfiles vendus. L’output est une tableau avec le package, le type de hook, le contenu du script et le dernier moment d’actualisation. Dans une équipe d’ingénierie moyenne, il y a généralement 200 à 500 hooks.

Étape 2: Classer par profil de risque. Les hooks qui exécutent uniquement des scripts de build locaux (par exemple node-gyp rebuild pour les extensions natives) sont non critiques. Les hooks qui téléchargent des scripts externes, font des appels curl arbitraires ou lisent des chemins .env en clair sont critiques. La classification peut être automatisée via une recherche de motifs simple dans le contenu des hooks, mais chaque package trouvé nécessite un révision manuelle.

Étape 3: Vérifier la configuration CI pour la protection des hooks. npm propose avec le flag –ignore-scripts la possibilité de désactiver tous les hooks lors de l’install. Pour les builds CI, c’est souvent un compromis acceptable car la plupart des étapes de build ont une configuration separate pour les extensions natives et les scripts de build. Celui qui a déjà mis ce flag dans CI a eu la chance le 22 avril.

Étape 4: Définir une règle de détection au niveau SIEM. Une règle qui signale les connexions sortantes vers des sous-domaines inconnus d’audit, de télémétrie ou d’analyse à partir des contextes de build npm est la couche de détection efficace. Dans le cas de Bitwarden, le sous-domaine était audit.checkmarx.cx, une adresse stylisée pour la crédibilité. Une expression régulière pour sous-domaines qui imitent des outils de confiance typiques peut capturer des vecteurs similaires à l’avenir.

Qu’est-ce qui s’arrête et qu’est-ce qui porte dans l’audit des hooks

La pratique tirée de la réaction à Bitwarden a montré des modèles clairs sur les approches de détection efficaces et celles qui s’arrêtent dans le théâtre de la sécurité.

La modification la plus importante est le paramètre CI par défaut. Si chaque nouveau conteneur de build démarre sans hooks actifs et qu’ils sont activés uniquement là où ils sont techniquement nécessaires, l’espace d’attaque réduit d’ordres de grandeur. C’est une mesure qui ne prend pas beaucoup de temps à communiquer et ne coûte pas des jours, mais des heures.

Ce que les équipes Sec doivent faire dès maintenant

Mesures concrètes pour la semaine suivant l’incident : Premièrement, exécuter le commande npm-Audit avec un filtre de date sur les logs des CI-Runs personnalisés du 22 avril entre 17:57 et 19:30 ET pour vérifier si @bitwarden/cli@2026.4.0 a été installé dans cette période. Deuxièmement, rotater tous les tokens, clés SSH et contenus .env des environnements de build potentiellement exposés. Troisièmement, intégrer la règle de détection contre l’egress de sous-domain audit dans le SIEM, préférablement en tant qu’alerte de gravité moyenne, car des faux positifs existent avec le trafic audit légitimes des sous-domaines.

Tâche à moyen terme : l’inventaire des hooks. Cela fait partie de la documentation NIS2 de la chaîne d’approvisionnement, car les packages npm sont officiellement des fournisseurs de logiciels. La attaque de l’acquisition de plugin dans WordPress et l’incident Bitwarden sont techniquement différents, mais réglementairement identiques : ces deux sont des risques de chaîne d’approvisionnement couverts par l’article 21 de NIS2 et doivent être documentés dans le registre des risques.

Practiquement, un élément du registre des risques par chaîne d’approvisionnement : quelles pipelines de build utilisent npm dans quel contexte d’account, quelles couches de détection sont en place, quelle est la fréquence de rotation des tokens, et qui est le propriétaire des risques. La plupart des assureurs et banques DACH ont le schéma déjà dans leur mapping DORA, mais doivent l’adapter spécifiquement aux builds npm. La portée des dommages d’un seul exfiltré GitHub-token avec des droits d’écriture sur les référentiels de production est généralement dans les six chiffres, car ce token ouvre non seulement un chemin, mais est un levier pour le mouvement latéral dans l’ensemble de l’écosystème technique.

Une deuxième couche souvent oubliée : le caching des builds. Certains setups npm CI cachent les node_modules entre les builds pour gagner du temps. Si le hook malveillant a été exécuté dans un build, l’effet du code malveillant persiste dans le cache, even after the package has been removed from the lockfile. L’enquête forensique après l’incident Bitwarden doit explicitement inclure les répertoires de cache, sinon un risque reste, qui pourrait être réactivé lors du prochain lancement de build. Celui qui ne peut pas invalidater selectivement le cache fait mieux de faire un nettoyage complet du cache plutôt qu’un patchage.

Sur le côté des outils, la situation s’est légèrement améliorée depuis le premier trimestre 2026. Les outils open-source tels que Socket, Endor Labs Open Source et Snyk ont développé des règles de détection spécifiques au comportement des hooks, qui étaient disponibles dans quelques heures après l’incident Bitwarden. Quiconque a l’un de ces outils dans sa pile devrait vérifier les packs de règles associés et les intégrer à l’ingestion SIEM. La faille de détection est moins large, mais la partie audit obligatoire reste, car aucun des outils ne fournit une classification complète des hooks. C’est une tâche de discipline qui ne doit pas être absente de la feuille de route de sécurité DACH au cours des prochaines quatre mois, car l’effort de l’inventaire des hooks est plus faible que les coûts conséquents d’une seule pipeline de build compromise avec des tokens productifs. La responsabilité opérationnelle incombe au team de sécurité des applications, la documentation formelle au bureau du CISO, et le rapport de statut deux fois par an devant le comité de risque, car les risques de chaîne d’approvisionnement ne sont plus une simple discipline d’ingénierie, mais une position de risque directement mesurée au niveau de l’entreprise. Quiconque travaille en 2026 sans cette triplet (inventaire des hooks, documentation, rapport) a peu de personnel, mais une attribution de rôles obsolète, qui peut être corrigée en une journée de workshop, une proposition de conseil d’administration et une révision halbé annuelle sans dépense de budget externe ou en attendant le prochain audit externe.

Conclusion

Foire aux questions

Suis-je concerné si j’ai installé le CLI Bitwarden le 22 avril ?

Seulement si l’installation a eu lieu entre 17:57 et 19:30 ET depuis le npm-Registry. Les utilisateurs qui n’ont pas installé dans cette période ne sont pas concernés. Les utilisateurs qui ont installé dans cette fenêtre doivent rotater tous les tokens et clés accessibles dans l’environnement de build.

Est-ce suffisant de déinstaller le package ?

Non. Le code malveillant a already exfiltré des données dans le hook de pré-installation, et la déinstallation ne supprime que le package, pas les conséquences. La rotation des tokens, des clés SSH et la vérification du contenu du fichier .env sont obligatoires.

Est-ce que la recommandation –ignore-scripts s’applique également aux machines de développement locales ?

Localement, c’est plus compliqué, car de nombreux outils de développement utilisent des extensions natives ou des hooks de build qui ne fonctionnent pas sans hook. Il est plus sage d’utiliser une liste d’autorisation différenciée uniquement pour les packages réellement nécessaires, plus une hardening de l’environnement de shell local contre les connexions sortantes non signées.

Quelles sont les domaines que les équipes de sécurité devraient surveiller sur la watchlist ?

Les sous-domaines qui imitent des noms de trust tools typiques (audit.*, telemetry.*, sbom.*, supply.*) et qui apparaissent pour la première fois dans le contexte de build npm. La watchlist devrait être comparée aux domaines des trust tools réellement utilisés pour réduire les faux positifs.

Pourquoi c’est-ce un incident relevant NIS2, bien que Bitwarden soit une entreprise américaine ?

Article 21 de NIS2 exige un manuel de gestion des risques de chaîne d’approvisionnement pour les secteurs critiques. Les packages npm et les outils CLI font partie de la chaîne d’approvisionnement logicielle et sont donc couverts, indépendamment du siège de l’offreur. La responsabilité de la documentation incombe au utilisateur allemand, pas à l’offreur américain.

Plus du réseau MBF Media

Source image de couverture : Pexels / Rahul Pandit (px:1933900)

À propos de l'auteur: Alec Chizhik

Plus d'articles de Alec Chizhik