En bref
Que s'est-il passé ?
Le ver Shai-Hulud pivote vers le multi-cloud : 29 heures après mbt et @cap-js/sqlite, il compromet intercom-client@7.0.4 (SDK officiel Intercom, ~361 510 téléchargements/semaine).
La version malveillante est publiée le 30 avril 2026 à 14h41 UTC via un pipeline OIDC GitHub Actions détourné, confirmant la propagation par la CI/CD volée aux victimes précédentes. Le preinstall node setup.mjs charge un voleur (router_runtime.js) via Bun.
Le voleur étend sa collecte au multi-cloud : credentials AWS via l'IMDS (169.254.169.254), jetons GCP, chaînes Azure, clés privées. Les attestations SLSA présentes en 7.0.3 disparaissent en 7.0.4 ; le paquet passe de 6 à 17,8 Mo.
Identités de publication courtes et gate d'approbation sur les pipelines OIDC, blocage de l'IMDS en CI (IMDSv2, hop limit), épinglage et vérification des attestations SLSA avant adoption.
Chronologie de l'attaque
À 14h41 UTC, intercom-client@7.0.4 est publié via un pipeline OIDC détourné, 29 heures après les deux premiers paquets de la vague.
Comment l'attaquant a procédé
Cet incident met en jeu les vecteurs d'attaque suivants du catalogue SOCLE ; chacun renvoie à sa fiche, où l'on trouve les exigences qui le neutralisent :
La leçon à en tirer
Identités de publication courtes (OIDC) ; détection de republication ; confinement du rayon d'explosion (egress filtre).
Les exigences SOCLE qui auraient limité cet incident
Cet incident se rattache à 23 exigences du référentiel, par domaine. Les satisfaire n'aurait pas forcément tout empêché, mais aurait réduit la probabilité de l'attaque, limité son impact ou accéléré sa détection :