Il suffit d’un workflow GitHub Actions mal ficelé pour transformer un projet open source respecté en distributeur de malware. Quatre paquets npm de l’écosystème AsyncAPI ont été compromis le 14 juillet 2026 dans une attaque de la chaîne d’approvisionnement logicielle. Cinq versions malveillantes ont été publiées sous l’espace de noms @asyncapi, embarquant un implant capable de voler des identifiants, d’ouvrir une porte dérobée et de s’installer durablement sur la machine infectée.
Les paquets touchés ne sont pas des inconnus : @asyncapi/specs, @asyncapi/generator, @asyncapi/generator-helpers et @asyncapi/generator-components. Autant de dépendances très largement tirées par les développeurs, ce qui donne à l’affaire une portée bien au-delà d’un projet de niche.
Points clés
- Cinq versions malveillantes publiées sous @asyncapi le 14 juillet 2026 via un workflow GitHub Actions mal configuré
- Les paquets touchés cumulaient plus de 3 millions de téléchargements hebdomadaires
- L’implant s’exécute au chargement par Node.js et vole identifiants, clés SSH, jetons et secrets cloud
- Retour recommandé aux versions saines et réinitialisation de tous les secrets exposés
Une publication signée par le pipeline lui-même
Les analyses de Chainguard, StepSecurity, Socket et SafeDep convergent sur un même scénario. L’attaquant aurait obtenu un accès de publication en abusant d’un workflow GitHub Actions mal configuré, avant de déclencher la chaîne de release officielle du projet. Dans plusieurs rapports, l’étape relève d’une campagne de type pwn request, où le mécanisme de publication approuvé par le dépôt sert lui-même de rampe de lancement au code malveillant.
Les versions incriminées sont @asyncapi/generator 3.3.1, @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1, ainsi que @asyncapi/specs 6.11.2 et 6.11.2-alpha.1. Les publications ont eu lieu en deux salves le 14 juillet 2026, certaines à quelques secondes d’intervalle. Les versions ont ensuite été retirées du registre npm.
Les paquets concernés cumulaient plus de 2,9 millions de téléchargements hebdomadaires selon certaines estimations, dont environ 2,7 millions pour le seul @asyncapi/specs. D’autres enquêtes évoquent un total supérieur à 3 millions de téléchargements par semaine pour l’ensemble des paquets touchés.
Un implant qui se réveille à l’import, pas à l’installation
Oubliez le simple vol de jeton. Les chercheurs décrivent un trojan d’accès à distance et un chargeur multi-étapes, souvent rattaché à la famille Miasma. Détail qui change tout : le code s’exécute au moment où le module est chargé par Node.js, et pas seulement à l’installation. De quoi contaminer les environnements de développement, les runners CI et le moindre script qui importe ces paquets.
Les données visées incluent les mots de passe et cookies des navigateurs, les clés SSH, les jetons npm et GitHub, les secrets AWS, les identifiants de GitHub CLI, les fichiers de configuration Docker et, sur macOS, le trousseau système. Certaines analyses mentionnent aussi des portefeuilles de cryptomonnaies.
D’après Socket, l’implant assure sa persistance via un téléchargement secondaire depuis IPFS, puis lance un processus Node détaché. Le malware établit ensuite un canal de commande et contrôle et peut recevoir des ordres à distance. Certaines variantes embarquaient des fonctions supplémentaires (vol d’identifiants, propagation) qui semblaient inactives dans l’échantillon étudié.
Ce que les équipes doivent vérifier
La consigne des chercheurs est nette : toute machine ayant importé l’une des versions concernées doit être considérée comme potentiellement compromise. Dépôts, lockfiles, caches npm, images de build et miroirs internes passent au crible. Le retour aux versions saines s’impose : @asyncapi/generator 3.3.0, @asyncapi/generator-helpers 1.1.0, @asyncapi/generator-components 0.7.0 et @asyncapi/specs 6.11.1.
Les équipes de sécurité insistent sur un point : réinitialiser les secrets exposés depuis une machine de confiance (jetons npm, accès GitHub, secrets CI/CD, identifiants cloud, clés SSH et sessions navigateur). Dans un environnement de build, la simple présence d’un module compromis suffit à traiter l’exécution comme un incident à part entière, même si l’infection est passée par un banal import.
