Provenance valide, attestations SLSA au vert, code pourri jusqu’à l’os. Quatre paquets npm du namespace @asyncapi ont été piégés après une intrusion dans les dépôts GitHub du projet, puis publiés via les propres workflows GitHub Actions du mainteneur. Résultat : un malware multi-étage récupéré depuis IPFS, distribué avec un tampon de provenance parfaitement en règle. La supply chain avait un bon dossier, mais un passager clandestin.
L’incident vise l’écosystème AsyncAPI, projet open source dédié à la description d’API événementielles. Les versions vérolées ont été publiées le 14 juillet 2026 avant d’être retirées du registre npm après détection. À elles quatre, les bibliothèques concernées pesaient un peu plus de 2,9 millions de téléchargements hebdomadaires.
Points clés
- Cinq versions de quatre paquets @asyncapi (2,9 millions de téléchargements hebdomadaires) ont été piégées le 14 juillet 2026.
- La publication est passée par les workflows GitHub Actions légitimes avec attestations OIDC/SLSA valides, le dépôt source ayant été compromis en amont.
- Le malware, baptisé Miasma, se charge à l’import, télécharge un second étage sur IPFS et installe un comportement de type botnet.
- Machines exposées à contrôler : lockfiles, caches, processus Node.js détachés, fichier sync.js, et rotation des secrets npm/GitHub/cloud/SSH.
Quatre paquets, cinq versions vérolées
Les versions compromises sont @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected] et @asyncapi/[email protected]. Deux vagues ont été repérées : une première autour du dépôt asyncapi/generator, une seconde dans asyncapi/spec-json-schemas.
L’attaquant a obtenu un accès en écriture sur les dépôts, puis a laissé les pipelines légitimes faire le sale boulot. Les métadonnées npm attribuent les publications à GitHub Actions via le mécanisme de publication de confiance OIDC, avec des attestations SLSA valides. Comme le détaille StepSecurity dans son analyse, le problème ne vient pas d’un faux artefact de build : le dépôt source était déjà compromis avant l’exécution du workflow.
« Les paquets ont été publiés via le workflow de release GitHub Actions légitime du projet et portent des attestations de provenance OIDC npm valides », écrit StepSecurity dans son billet de recherche.
Chargement à l’import, IPFS et botnet à étages
Le code injecté ne se déclenche pas à l’installation mais au moment de l’import ou du require du module. Détail crucial pour les environnements de développement, les chaînes CI et les outils internes qui chargent ces bibliothèques en automatique. Une fois exécuté, le premier étage lance un processus Node.js détaché, puis va chercher un second composant chiffré sur IPFS, le protocole de stockage distribué.
Les chercheurs décrivent une chaîne plus vaste, baptisée Miasma. Les charges utiles observées établissent la persistance et ouvrent des fonctions d’accès à distance. L’analyse publiée par Socket cite aussi des canaux de secours via passerelles IPFS, relais Nostr et mécanismes peer-to-peer, avec un comportement de type botnet et de la collecte de secrets sur les machines infectées.
- ciblage des postes de développement et des serveurs CI/CD ;
- chargement du code malveillant à l’import, pas à l’installation ;
- récupération du second étage depuis IPFS ;
- persistance via un processus Node.js détaché ;
- risque sur les jetons npm, GitHub, cloud et SSH présents sur les machines exposées.
Ce que les équipes doivent vérifier
Les versions propres sont @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected] et @asyncapi/[email protected]. Les installations neuves ne devraient plus attraper les versions retirées du registre, mais toute machine ayant chargé une version piégée reste concernée tant qu’elle n’a pas été contrôlée.
Les recommandations des équipes de réponse à incident convergent : vérifier les lockfiles, les caches, les images de build et les dépôts miroir internes, traquer tout processus Node.js détaché, inspecter les répertoires utilisateurs à la recherche d’un fichier sync.js, puis réinitialiser tous les secrets accessibles depuis les environnements touchés. Jetons npm, accès GitHub, identifiants cloud et clés SSH sont à considérer comme grillés dès qu’un module a été importé sur une machine sensible.
La leçon tient en une ligne : une chaîne de publication authentique a servi à livrer du code malveillant, et les attestations de provenance n’ont rien empêché parce que la corruption avait eu lieu bien en amont. La provenance vous dit d’où vient le colis, pas ce qu’on a glissé dedans.
