{"id":13736,"date":"2026-04-28T09:18:51","date_gmt":"2026-04-28T09:18:51","guid":{"rendered":"https:\/\/www.securitytoday.de\/2026\/04\/29\/bitwarden-cli-checkmarx-github-action-supply-chain-devsecops\/"},"modified":"2026-07-09T16:50:51","modified_gmt":"2026-07-09T16:50:51","slug":"bitwarden-cli-checkmarx-github-action-supply-chain-devsecops","status":"publish","type":"post","link":"https:\/\/www.securitytoday.de\/fr\/2026\/04\/28\/bitwarden-cli-checkmarx-github-action-supply-chain-devsecops\/","title":{"rendered":"Attaque de la cha\u00eene d’approvisionnement via GitHub Actions contre Bitwarden CLI"},"content":{"rendered":"
7 Min. Temps de lecture<\/div>\n

L’incident de Bitwarden-CLI du 22 avril 2026 n’est pas une panne de biblioth\u00e8que, mais un probl\u00e8me de pipeline. L’action GitHub compromise checkmarx\/ast-github-action a rendu les tokens et les mat\u00e9riaux de construction de Bitwarden accessibles \u00e0 des attaques – et a ainsi distribu\u00e9 bri\u00e8vement @bitwarden\/cli@2026.4.0 sur npm. Les responsables DACH-DevSecOps v\u00e9rifient maintenant non pas le CLI, mais les machines de construction environnantes.<\/strong><\/p>\n

\n

Les points cl\u00e9s en bref<\/p>\n

    \n
  • Incident.<\/strong> Entre 23h57 et 01h30 CEST dans la nuit du 22 au 23 avril 2026, une variante compromise de @bitwarden\/cli@2026.4.0 \u00e9tait disponible sur npm. Bitwarden a depuis d\u00e9pr\u00e9ci\u00e9 la version.<\/li>\n
  • Cause profonde.<\/strong> Une action de fournisseur tiers compromise nomm\u00e9e checkmarx\/ast-github-action dans le workflow GitHub de Bitwarden a permis l’exfiltration de secrets de workflow.<\/li>\n
  • Impact.<\/strong> Le payload bw1.js a collect\u00e9 les tokens GitHub\/npm, les cl\u00e9s SSH, les variables d’environnement et les informations d’identification cloud lors de l’installation de npm. Les donn\u00e9es de vault des utilisateurs finaux n’ont pas \u00e9t\u00e9 affect\u00e9es selon Bitwarden.<\/li>\n
  • V\u00e9rifications obligatoires.<\/strong> Inventaire des CI-Runner, hash pinning pour les actions de tiers, audit de lockfile et de cache, rotation des tokens, filtres de sortie sur les build-runner.<\/li>\n<\/ul>\n<\/div>\n
    \n

    Qu’est-ce qu’une attaque de la cha\u00eene d’approvisionnement via GitHub Actions ?<\/strong> Une attaque de la cha\u00eene d’approvisionnement via GitHub Actions est une classe d’attaque o\u00f9 les attaquants ne compromettent pas le paquet logiciel lui-m\u00eame, mais une action de fournisseur tiers int\u00e9gr\u00e9e dans le workflow de construction. Cette action obtient l’acc\u00e8s aux secrets de workflow (tokens, informations d’identification cloud) lors de l’ex\u00e9cution, qu’elle peut exfiltrer vers un point de terminaison contr\u00f4l\u00e9 par l’attaquant. Avec les tokens vol\u00e9s, il est possible de manipuler les versions, d’\u00e9crire dans des d\u00e9p\u00f4ts \u00e9trangers ou de prendre le contr\u00f4le de ressources cloud – cela n’est remarqu\u00e9 par le client final que lorsque le paquet construit est visible sur le canal de distribution.<\/p>\n<\/div>\n

    Pourquoi cet incident est un incident de pipeline, pas un incident de CLI<\/h2>\n

    L’interpr\u00e9tation m\u00e9diatique de l’\u00e9pisode Bitwarden est incompl\u00e8te : un gestionnaire de mots de passe CLI aurait \u00e9t\u00e9 compromis, donc les donn\u00e9es de Vault seraient en danger. Ce n’\u00e9tait pas exactement cela. La d\u00e9claration officielle de Bitwarden confirme une distribution de 93 minutes via npm et exclut explicitement un acc\u00e8s aux contenus de Vault. Le v\u00e9ritable probl\u00e8me se situe \u00e0 une couche plus profonde – dans le workflow CI\/CD qui a construit et publi\u00e9 le CLI.<\/p>\n

    Le r\u00e9f\u00e9rentiel GitHub de Bitwarden utilise – comme de nombreux stacks DevSecOps – une action de tiers appel\u00e9e checkmarx\/ast-github-action pour l’analyse statique. Cette action a \u00e9t\u00e9 pr\u00e9par\u00e9e dans le cadre d’une campagne plus large de compromission de la cha\u00eene d’approvisionnement de Checkmarx et a exfiltr\u00e9 des secrets de workflow. Avec les tokens obtenus, l’attaquant a bri\u00e8vement infiltr\u00e9 le travail de publication et a pouss\u00e9 une variante modifi\u00e9e de la version 2026.4.0 sur le canal npm. Des chercheurs en s\u00e9curit\u00e9 de Socket, Endor Labs et Palo Alto Networks ont ind\u00e9pendamment reconstitu\u00e9 la m\u00e9canique, le payload bw1.js a collect\u00e9 les tokens GitHub et npm, les cl\u00e9s SSH, l’historique des shells ainsi que les informations d’identification cloud et les a envoy\u00e9s chiffr\u00e9s AES-256-GCM \u00e0 la domaine imit\u00e9e audit.checkmarx.cx.<\/p>\n

    Pour les responsables DACH, cela signifie : chaque organisation qui utilise GitHub Actions est potentiellement expos\u00e9e de la m\u00eame mani\u00e8re – ind\u00e9pendamment de la pr\u00e9sence de Bitwarden CLI dans le stack. L’attaque ne vise pas le paquet publi\u00e9, mais le point dans le workflow o\u00f9 une \u00e9tape de tiers obtient l’acc\u00e8s aux secrets de travail. Quiconque utilise des workflows GitHub avec des r\u00e9f\u00e9rences uses sans hash-pinning charge \u00e0 chaque ex\u00e9cution l’\u00e9tat actuel de l’action externe – y compris une compromission qui peut s’\u00eatre produite entre deux builds.<\/p>\n

    \n
    93 minutes<\/div>\n
    Fen\u00eatre de distribution de la version modifi\u00e9e de @bitwarden\/cli@2026.4.0 sur npm. Pendant ce temps, chaque ex\u00e9cution CI non surveill\u00e9e qui installait le CLI comme d\u00e9pendance a tir\u00e9 le payload pr\u00e9par\u00e9.<\/div>\n
    Source : D\u00e9claration de Bitwarden sur l’incident de la cha\u00eene d’approvisionnement Checkmarx, 23 avril 2026<\/div>\n<\/div>\n

    Trois couches que les \u00e9quipes DevSecOps doivent parcourir maintenant<\/h2>\n

    L’examen se d\u00e9roule de mani\u00e8re pragmatique en trois couches. Qu’est-ce qui s’est r\u00e9ellement pass\u00e9 sur les Build-Runner ces derni\u00e8res semaines ? Quels Secrets \u00e9taient disponibles ? Quels \u00e9tapes de tiers avaient un acc\u00e8s en lecture ou en \u00e9criture au contexte de Workflow ? Ce n’est qu’apr\u00e8s avoir r\u00e9pondu \u00e0 ces trois questions que l’analyse de la version CLI et du fichier de verrouillage peut \u00eatre effectu\u00e9e.<\/p>\n

    La premi\u00e8re couche est l’inventaire des CI-Runner<\/strong>. Chaque Build-Runner qui a ex\u00e9cut\u00e9 des Workflows entre le 22 avril au soir et le 24 avril \u00e0 midi doit figurer dans une liste avec l’ID de course, le nom du travail, les Actions impliqu\u00e9es et l’image de conteneur d\u00e9marr\u00e9e. Les Self-hosted Runner sont particuli\u00e8rement critiques car ils conservent l’\u00e9tat entre les travaux – si un Workflow pr\u00e9par\u00e9 a \u00e9crit des jetons dans le cache du Runner, ils y restent m\u00eame apr\u00e8s le nettoyage de Bitwarden. Les GitHub-hosted Runner sont \u00e9ph\u00e9m\u00e8res, mais les journaux de course montrent les versions d’Action charg\u00e9es \u00e9galement.<\/p>\n

    La deuxi\u00e8me couche est le stock de Secrets<\/strong>. Les jetons r\u00e9f\u00e9renc\u00e9s dans un travail affect\u00e9 sont consid\u00e9r\u00e9s comme compromis – m\u00eame si le travail s’est d\u00e9roul\u00e9 proprement. Cela inclut les Secrets de r\u00e9f\u00e9rentiel, d’organisation et d’environnement, les jetons OIDC-Issuer, les jetons npm-Publish, les PAT GitHub ainsi que les informations d’identification Cloud qui ont \u00e9t\u00e9 inject\u00e9es dans le travail via la f\u00e9d\u00e9ration. La rotation n’a pas besoin de se faire de mani\u00e8re panique, mais elle doit se d\u00e9rouler dans un ordre document\u00e9, car les jetons rotatifs sont r\u00e9f\u00e9renc\u00e9s en parall\u00e8le dans les syst\u00e8mes de production.<\/p>\n

    La troisi\u00e8me couche est l’inventaire des Actions<\/strong>. Quelles Actions de tiers se trouvent dans vos propres Workflows ? Lesquelles sont r\u00e9f\u00e9renc\u00e9es par date (@v3), lesquelles par hachage ? Le Tag-Pinning ressemble \u00e0 une version, mais ne fournit aucune garantie – un attaquant avec un acc\u00e8s Maintainer peut suspendre le tag \u00e0 un commit compromis. Le Hash-Pinning fige l’Action sur un SHA de commit exact et exclut cette classe d’attaques.<\/p>\n

    \n

    Ordre de v\u00e9rification aigu pour les \u00e9quipes DevSecOps DACH<\/p>\n

    1. Exporter les journaux d’audit GitHub des 7 derniers jours et rechercher les pouss\u00e9es de fichiers de Workflow ainsi que l’utilisation de jetons d’Action contre des domaines externes. 2. Supprimer checkmarx\/ast-github-action de chaque Workflow ou l’\u00e9pingler sur un SHA de commit ant\u00e9rieur au 22 avril. 3. Faire tourner tous les Secrets de r\u00e9f\u00e9rentiel, d’organisation et d’environnement qui ont \u00e9t\u00e9 r\u00e9f\u00e9renc\u00e9s dans un Workflow entre le 22 et le 24 avril. 4. V\u00e9rifier les fichiers de verrouillage npm sur @bitwarden\/cli@2026.4.0 et downgrader \u00e0 une version pr\u00e9c\u00e9dente si n\u00e9cessaire. 5. Activer la r\u00e8gle SIEM qui signale les connexions \u00e0 audit.checkmarx.cx.<\/p>\n<\/div>\n

    Ce qui agit imm\u00e9diatement – et ce qui ne procure qu’une s\u00e9curit\u00e9 apparente<\/h2>\n

    La communaut\u00e9 DevSecOps d\u00e9bat depuis des jours sur les mesures qui sont vraiment efficaces. Certains r\u00e9flexes sont op\u00e9rationnellement corrects, d’autres procurent une fausse s\u00e9curit\u00e9. L’\u00e9valuation suivante s\u00e9pare les mesures obligatoires des mesures souhait\u00e9es.<\/p>\n

    \n
    \n

    Agit imm\u00e9diatement<\/p>\n