8 min. de lecture<\/p>\n
Le soir du 22 avril, un paquet malicieux de Bitwarden-CLI a \u00e9t\u00e9 pr\u00e9sent dans le npm-Registry pendant 93 minutes, livr\u00e9 via la distribution officielle de Bitwarden. Le code malveillant a \u00e9t\u00e9 ex\u00e9cut\u00e9 dans le hook de pr\u00e9-installation et a extrait des jetons GitHub, des cl\u00e9s SSH, des fichiers .env et des secrets de cloud vers une subdomain audit.checkmarx.cx. Le v\u00e9ritable probl\u00e8me n’est pas le paquet captur\u00e9. Le v\u00e9ritable probl\u00e8me est que les \u00e9quipes de s\u00e9curit\u00e9 DACH n’auront pas encore effectu\u00e9 une inventaire de leurs hooks de pr\u00e9-installation en 2026.<\/strong><\/p>\n Les points cl\u00e9s en bref<\/p>\n Qu’est-ce qu’un hook de pr\u00e9-installation ?<\/strong> Un hook de pr\u00e9-installation est un script qui est automatiquement ex\u00e9cut\u00e9 par le gestionnaire de paquets npm avant l’installation ou l’utilisation du paquet en question. Il est d\u00e9fini dans le champ scripts.preinstall de la package.json. Le hook a les m\u00eames droits que le processus de build en cours et peut lire n’importe quelle file, \u00e9tablir des connexions r\u00e9seau et exfiltrer des donn\u00e9es. Il a \u00e9t\u00e9 initialement con\u00e7u pour ex\u00e9cuter des \u00e9tapes 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\u00e9cution de code le plus courant dans les attaques de la cha\u00eene d’approvisionnement npm, car il s’ex\u00e9cute sans aucune action de l’utilisateur.<\/p>\n Les types de hooks associ\u00e9s sont install (pendant l’installation), postinstall (apr\u00e8s) et prepare (lors du git clone dans les d\u00e9pendances). Tous les trois ont les m\u00eames droits et les m\u00eames types de risques. Un inventaire complet des hooks doit couvrir les quatre.<\/p>\n Le sc\u00e9nario de pr\u00e9installation de Bitwarden-CLI a eu un chronologie clairement document\u00e9e. Le Bitwarden Security Team a reconstruit le paquet infect\u00e9 avec des minutes pr\u00e9cises dans le forum communautaire Bitwarden officiel.<\/p>\n Le fen\u00eatre de 93 minutes peut para\u00eetre petite, mais dans le contexte npm, elle est suffisamment grande pour affecter des milliers de builds automatis\u00e9es. Toute pipeline CI qui a lanc\u00e9 un nouveau conteneur et install\u00e9 @bitwarden\/cli dans cette p\u00e9riode a ex\u00e9cut\u00e9 le hook de pr\u00e9installation. L’exfiltration s’est d\u00e9roul\u00e9e sans journalisation visible dans le flux de sortie npm par d\u00e9faut.<\/p>\n La r\u00e9action usuelle \u00e0 un incident npm consiste \u00e0 supprimer le package du Lockfile, le r\u00e9installer et continuer \u00e0 travailler. Cela soulage le sympt\u00f4me, mais ne r\u00e9sout pas le m\u00e9canisme. Le m\u00e9canisme en question est la fonctionnalit\u00e9 de script de pr\u00e9installation de npm, qui ex\u00e9cute un script avant que le package ne soit utilis\u00e9 de quelque mani\u00e8re que ce soit lors de l’installation. Dans le sc\u00e9nario Bitwarden, aucun utilisateur n’a activement appel\u00e9 le CLI-Tool pour d\u00e9clencher l’exfiltration. Il suffit d’avoir fait npm install.<\/p>\n La plupart des \u00e9quipes d’ing\u00e9nierie ne peuvent pas dire combien de leurs d\u00e9pendances directes ont un hook de pr\u00e9installation. Les d\u00e9pendances transitives sont encore plus pr\u00e9judiciables. Un projet Node.js standard avec cinq cents d\u00e9pendances transitives a g\u00e9n\u00e9ralement entre dix et quarante packages avec des hooks de pr\u00e9installation, install ou postinstall. Chacun de ces hooks est un vecteur d’ex\u00e9cution de code, o\u00f9 le temps de r\u00e9vision est nul. L’attaque Axios-npm<\/a> avait le m\u00eame m\u00e9canisme, mais avec un autre compte de maintainer comme point d’entr\u00e9e.<\/p>\n Les \u00e9quipes Sec peuvent commencer \u00e0 inventorier leurs hooks lors d’un jour de formation. Quatre \u00e9tapes suffisent pour un aper\u00e7u initial qui peut \u00eatre utilis\u00e9 imm\u00e9diatement comme base de d\u00e9tection.<\/p>\n \u00c9tape 1: Inventorier tous les scripts de pr\u00e9install, d’install et de postinstall \u00e0 travers tous les r\u00e9f\u00e9rentiels.<\/strong> L’outil standard est npm-audit-resolver ou un script simple qui parse chaque package.json dans les r\u00e9f\u00e9rentiels 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 \u00e9quipe d’ing\u00e9nierie moyenne, il y a g\u00e9n\u00e9ralement 200 \u00e0 500 hooks.<\/p>\n \u00c9tape 2: Classer par profil de risque.<\/strong> Les hooks qui ex\u00e9cutent uniquement des scripts de build locaux (par exemple node-gyp rebuild pour les extensions natives) sont non critiques. Les hooks qui t\u00e9l\u00e9chargent des scripts externes, font des appels curl arbitraires ou lisent des chemins .env en clair sont critiques. La classification peut \u00eatre automatis\u00e9e via une recherche de motifs simple dans le contenu des hooks, mais chaque package trouv\u00e9 n\u00e9cessite un r\u00e9vision manuelle.<\/p>\n \u00c9tape 3: V\u00e9rifier la configuration CI pour la protection des hooks.<\/strong> npm propose avec le flag –ignore-scripts la possibilit\u00e9 de d\u00e9sactiver tous les hooks lors de l’install. Pour les builds CI, c’est souvent un compromis acceptable car la plupart des \u00e9tapes de build ont une configuration separate pour les extensions natives et les scripts de build. Celui qui a d\u00e9j\u00e0 mis ce flag dans CI a eu la chance le 22 avril.<\/p>\n \u00c9tape 4: D\u00e9finir une r\u00e8gle de d\u00e9tection au niveau SIEM.<\/strong> Une r\u00e8gle qui signale les connexions sortantes vers des sous-domaines inconnus d’audit, de t\u00e9l\u00e9m\u00e9trie ou d’analyse \u00e0 partir des contextes de build npm est la couche de d\u00e9tection efficace. Dans le cas de Bitwarden, le sous-domaine \u00e9tait audit.checkmarx.cx, une adresse stylis\u00e9e pour la cr\u00e9dibilit\u00e9. Une expression r\u00e9guli\u00e8re pour sous-domaines qui imitent des outils de confiance typiques peut capturer des vecteurs similaires \u00e0 l’avenir.<\/p>\n La pratique tir\u00e9e de la r\u00e9action \u00e0 Bitwarden a montr\u00e9 des mod\u00e8les clairs sur les approches de d\u00e9tection efficaces et celles qui s’arr\u00eatent dans le th\u00e9\u00e2tre de la s\u00e9curit\u00e9.<\/p>\n Qu’est-ce qui s’arr\u00eate<\/p>\n Qu’est-ce qui porte<\/p>\n La modification la plus importante est le param\u00e8tre CI par d\u00e9faut. Si chaque nouveau conteneur de build d\u00e9marre sans hooks actifs et qu’ils sont activ\u00e9s uniquement l\u00e0 o\u00f9 ils sont techniquement n\u00e9cessaires, l’espace d’attaque r\u00e9duit d’ordres de grandeur. C’est une mesure qui ne prend pas beaucoup de temps \u00e0 communiquer et ne co\u00fbte pas des jours, mais des heures.<\/p>\n Mesures concr\u00e8tes pour la semaine suivant l’incident : Premi\u00e8rement, ex\u00e9cuter le commande npm-Audit avec un filtre de date sur les logs des CI-Runs personnalis\u00e9s du 22 avril entre 17:57 et 19:30 ET pour v\u00e9rifier si @bitwarden\/cli@2026.4.0 a \u00e9t\u00e9 install\u00e9 dans cette p\u00e9riode. Deuxi\u00e8mement, rotater tous les tokens, cl\u00e9s SSH et contenus .env des environnements de build potentiellement expos\u00e9s. Troisi\u00e8mement, int\u00e9grer la r\u00e8gle de d\u00e9tection contre l’egress de sous-domain audit dans le SIEM, pr\u00e9f\u00e9rablement en tant qu’alerte de gravit\u00e9 moyenne, car des faux positifs existent avec le trafic audit l\u00e9gitimes des sous-domaines.<\/p>\n\n
Qu’est-ce qu’un hook de pr\u00e9-installation ?<\/h2>\n
Qu’est-ce qui s’est pass\u00e9, dans l’ordre<\/h2>\n
Pourquoi les hooks de pr\u00e9installation sont les v\u00e9ritables probl\u00e8mes<\/h2>\n
Audit de quatre \u00e9tapes pour les hooks de pr\u00e9install npm<\/h2>\n
Qu’est-ce qui s’arr\u00eate et qu’est-ce qui porte dans l’audit des hooks<\/h2>\n
\n
\n
Ce que les \u00e9quipes Sec doivent faire d\u00e8s maintenant<\/h2>\n