Points cl\u00e9s<\/p>\n
- \n
- L\u2019intrusion a d\u00e9but\u00e9 par une mauvaise configuration de la CI, bien avant le jeton de registre.<\/strong> Le workflow pull_request_target avec checkout de la branche non fiable, un GITHUB_TOKEN trop permissif et un push ult\u00e9rieur par un bot : l\u2019exfiltration de secrets et la compromission de branche vont de pair.<\/li>\n
- La charge utile dans le require(), l\u2019ex\u00e9cution active \u00e9tait plus \u00e9troite que le bundle.<\/strong> ShellExec, persistance et C2 fonctionnaient. Le harvesting, la propagation et l\u2019\u00e9vasion \u00e9taient inclus dans le paquet, mais d\u00e9sactiv\u00e9s dans cette livraison via un interrupteur.<\/li>\n
- Les fichiers de verrouillage (lockfiles) entre 07:10 et 11:18 UTC restent risqu\u00e9s.<\/strong> npm a supprim\u00e9 les versions concern\u00e9es ; les r\u00e9f\u00e9rences existantes et les caches CI ne le sont pas.<\/li>\n<\/ul>\n<\/div>\n
Articles associ\u00e9s :<\/span>Un paquet npm ayant vol\u00e9 des cl\u00e9s priv\u00e9es<\/a> \/<\/span> Mini Shai-Hulud : ver npm dans la cha\u00eene d\u2019approvisionnement et contre-mesures<\/a><\/p>\n
Ce qui s’est exactement pass\u00e9<\/h2>\n
Le 14 juillet 2026 \u00e0 06:58 UTC, un commit a \u00e9t\u00e9 pouss\u00e9 sur la branche *next* du d\u00e9p\u00f4t asyncapi\/generator sous l’identit\u00e9 factice \u00ab Votre nom \u00bb \/ you@example.com. Douze minutes plus tard, le workflow l\u00e9gitime release-with-changesets.yml a publi\u00e9 trois paquets avec une provenance OIDC npm valide : @asyncapi\/generator@3.3.1, @asyncapi\/generator-helpers@1.1.1 et @asyncapi\/generator-components@0.7.1.<\/p>\n
Selon le blog de s\u00e9curit\u00e9 de Microsoft, l’acc\u00e8s initial s’est produit via la PR #2155 contre le workflow manual-netlify-preview.yml. Ce workflow utilisait pull_request_target et v\u00e9rifiait le commit non fiable (untrusted) en provenance de la t\u00eate de la branche. Le GITHUB_TOKEN disposait de privil\u00e8ges \u00e9tendus ; les identifiants de checkout sont rest\u00e9s dans la configuration Git locale jusqu’au nettoyage post-job. Par la suite, des pushs ont \u00e9t\u00e9 effectu\u00e9s depuis le compte asyncapi-bot. Microsoft reste prudent quant \u00e0 la confirmation que ces identifiants ont \u00e9t\u00e9 pr\u00e9cis\u00e9ment vol\u00e9s. Cependant, l’encha\u00eenement de l’attaque via la requ\u00eate pwn et les pushs ult\u00e9rieurs via le bot sont av\u00e9r\u00e9s et expliquent l’acc\u00e8s \u00e0 la branche de release.<\/p>\n
Entre 07:51 et 08:30 UTC environ, le m\u00eame attaquant a cibl\u00e9 asyncapi\/spec-json-schemas (branche master). Via des commits avec le pr\u00e9fixe fix:, il a d\u00e9clench\u00e9 if-nodejs-release.yml et livr\u00e9 @asyncapi\/specs@6.11.2-alpha.1 ainsi que @asyncapi\/specs@6.11.2. StepSecurity, Socket, SafeDep et OX Security ont document\u00e9 la m\u00eame infrastructure de dropper et de deuxi\u00e8me niveau (selon StepSecurity : famille Miasma-v3).<\/p>\n
Pour contextualiser : aucun token npm de publication n’a \u00e9t\u00e9 vol\u00e9. Le processus de publication a emprunt\u00e9 le chemin OIDC Trusted Publishing. La faille de confiance se situe en amont, dans la CI et dans les droits de push sur la branche d\u00e9clenchant le workflow de release.<\/p>\n
\n~4 h<\/div>\nFen\u00eatre d’exposition jusqu’au retrait des paquets du g\u00e9n\u00e9rateur<\/p>\n
Source : Chronologie StepSecurity, 14.07.2026 UTC<\/p>\n<\/div>\n
Pourquoi la \u00ab provenance valide \u00bb peut \u00eatre trompeuse dans ce cas<\/h2>\n
Le syst\u00e8me npm Trusted Publishing avec OIDC et les attestations SLSA r\u00e9pondent \u00e0 une question pr\u00e9cise : cet artefact a-t-il \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9 par le workflow GitHub autoris\u00e9 de ce d\u00e9p\u00f4t ? L\u2019attestation des paquets g\u00e9n\u00e9rateurs indiquait exactement repo:asyncapi\/generator:ref:refs\/heads\/next, le fichier du workflow, le commit SHA et l\u2019URL de l\u2019ex\u00e9cution.<\/p>\n
En revanche, elle ne r\u00e9pond pas \u00e0 une autre question cruciale : le commit ayant d\u00e9clench\u00e9 le workflow \u00e9tait-il l\u00e9gitime et int\u00e8gre ? La provenance ne prot\u00e8ge pas contre des identifiants de push compromis ni contre des jobs CI ex\u00e9cutant du code non fiable avec des jetons privil\u00e9gi\u00e9s. Lorsque pull_request_target est combin\u00e9 avec un checkout de la t\u00eate de la PR, que des secrets sont laiss\u00e9s dans ces jobs et que la protection des branches est faible sur les branches de release, c\u2019est pr\u00e9cis\u00e9ment cette faille qui est exploit\u00e9e.<\/p>\n
Pour les RSSI (CISO) et les \u00e9quipes AppSec, c\u2019est le levier central : les signatures de registre et les indicateurs de provenance \u00e9valuent le cas AsyncAPI comme \u00ab vert \u00bb, alors que la CI a d\u00e9j\u00e0 livr\u00e9 le dropper. Les contr\u00f4les doivent v\u00e9rifier la source de v\u00e9rit\u00e9 ainsi que les permissions des workflows.<\/p>\n
M\u00e9canisme de charge utile sans hook d’installation<\/h2>\n
Aucun des fichiers package.json concern\u00e9s ne contenait de script preinstall\/postinstall. Le dropper s’activait d\u00e8s que le code du module empoisonn\u00e9 \u00e9tait charg\u00e9 via require(), c’est-\u00e0-dire lors de l’ex\u00e9cution normale du g\u00e9n\u00e9rateur ou dans les t\u00e2ches CI construisant des templates AsyncAPI.<\/p>\n
L’\u00e9tape 1 lance un processus Node d\u00e9tach\u00e9. L’\u00e9tape 2 r\u00e9cup\u00e8re depuis une passerelle IPFS un fichier sync.js, stock\u00e9 dans des chemins sp\u00e9cifiques au syst\u00e8me d’exploitation, se faisant passer pour une runtime NodeJS inoffensive (sous Linux, par exemple ~\/.local\/share\/NodeJS\/sync.js). L’\u00e9tape 3 d\u00e9chiffre un implant Miasma-v3 int\u00e9gr\u00e9. Dans la configuration livr\u00e9e, les fonctions de shell \u00e0 distance (ShellExec), de persistance et de balise C2 (command & control) s’ex\u00e9cutaient via plusieurs canaux (HTTP, Nostr, IPFS, DHT BitTorrent, dead-drop Ethereum).<\/p>\n
Les analyses statiques men\u00e9es par Aikido et Socket r\u00e9v\u00e8lent \u00e9galement des modules dans le bundle qui \u00e9taient d\u00e9sactiv\u00e9s dans cette livraison via des commutateurs : recon : false (le vol d’identifiants ne d\u00e9marre pas), metamorphic : false (mutation, \u00e9vasion et empoisonnement d’outils d’IA d\u00e9sactiv\u00e9s) ainsi que propagate pour npm\/pypi\/ruby\/cargo syst\u00e9matiquement \u00e0 false (aucune propagation lat\u00e9rale de paquets). Le magasin de l’artefact contenait l’implant. Cette vague d’attaque se limitait \u00e0 une coquille distante avec persistance et C2. L’analyse forensique des h\u00f4tes reste indispensable, car l’acc\u00e8s shell et la persistance \u00e9taient activ\u00e9s.<\/p>\n
\n - La charge utile dans le require(), l\u2019ex\u00e9cution active \u00e9tait plus \u00e9troite que le bundle.<\/strong> ShellExec, persistance et C2 fonctionnaient. Le harvesting, la propagation et l\u2019\u00e9vasion \u00e9taient inclus dans le paquet, mais d\u00e9sactiv\u00e9s dans cette livraison via un interrupteur.<\/li>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/cursor-windows-git-exe-repo-root-code-execution-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/legacyhive-windows-eop-poc-nach-patch-tuesday-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/joomla-icagenda-balbooa-kev-upload-rce-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-wenn-ki-agenten-reisen-data-residency-al-67057393.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-mehr-insolvenzen-kleinere-faelle-was-zae-22120048-250x143.jpg\")
<\/span>