Le 15 mai 2026, le groupe d’attaquants TeamPCP a publié sur plusieurs comptes GitHub le code source complet du ver Shai-Hulud, accompagné du message explicite « Open Sourcing The Carnage ». GitHub a retiré les dépôts dans les heures qui ont suivi, mais des forks circulent déjà — et selon les analyses d’Ox Security et de Datadog, plusieurs acteurs ont commencé à réutiliser le code dans des campagnes opportunistes dès la publication. Pour toute PME-ETI dont le SI dépend de bibliothèques open source ou de pipelines CI/CD, ce passage du closed-source au framework partagé change la donne stratégique : ce n’est plus une menace unique, mais une famille de variantes à venir. Voici l’analyse de ce qui a réellement changé, et la posture défensive à adopter dans les semaines qui viennent.
Ce que TeamPCP a publié et pourquoi c’est un point de bascule
Le dépôt contenait un framework modulaire — pas un simple script. D’après Datadog, l’arborescence inclut au moins six composants : loaders, modules de récolte de secrets, collecteur d’informations système, dispatcher, exfiltrateurs et mutateurs. C’est une boîte à outils prête à être personnalisée par n’importe quel attaquant. La conception est explicitement pensée pour le passage à l’échelle : chiffrement des données stagées, exfiltration vers des dépôts GitHub jetables ou des serveurs C&C contrôlés par l’opérateur, mécanisme de persistance et même un dead-man switch pour activer la charge si la connexion à l’opérateur est perdue.
Le détail technique le plus important pour les équipes de défense tient à un seul paragraphe de la documentation publiée : « une nouvelle passphrase aléatoire est générée à chaque build, deux builds des mêmes sources produisent des binaires différents ». Concrètement, cela signifie que les outils défensifs qui s’appuient sur les hashs de fichiers — le socle de la majorité des EDR et antivirus historiques — deviennent inopérants contre cette famille. Chaque attaquant qui clone le dépôt obtient mécaniquement un payload unique, indétectable par signature. Ben Ronallo (Black Duck) résume la situation sans détour : « TeamPCP turning the knob up to 11 on their activities by releasing this to anyone who wants to use it ».
Pourquoi c’est un saut qualitatif, pas une simple fuite de code
Les fuites de code malveillant arrivent régulièrement — Conti, Babuk, LockBit ont tous connu ce destin. Ce qui distingue le cas Shai-Hulud, c’est la combinaison de trois facteurs qui n’avaient jamais été réunis dans une fuite de famille worm supply-chain :
- Une architecture modulaire et documentée conçue pour la réutilisation. Un attaquant débutant peut combiner les briques sans réécrire la mécanique cœur.
- Un mécanisme polymorphique natif qui rend les hashs et règles YARA mono-binaires inopérants dès le premier rebuild.
- Une preuve d’efficacité opérationnelle préalable : la variante Mini Shai-Hulud a déjà compromis 84 paquets dans le namespace @tanstack le 11 mai (lire notre checklist de remédiation TanStack Mini Shai-Hulud), plus OpenSearch, Mistral AI et Guardrails AI dans la foulée. Les attaquants reprennent donc une recette qui a déjà fonctionné — pas un prototype.
Selon Ox Security, des campagnes utilisant le code modifié sont apparues dans les heures qui ont suivi la publication. Le délai entre « code disponible » et « code exploité » est tombé à moins d’une journée. Datadog anticipe ouvertement « une période d’innovation autour de Shai-Hulud, avec plusieurs variantes attendues ». Pour les défenseurs, cela signifie que le prochain incident ne sera pas une réplique mais une mutation — avec un payload différent, un canal d’exfiltration différent, peut-être un ciblage différent (PyPI, RubyGems, Maven en plus de npm).
Ce que cela change concrètement pour une PME-ETI
La défense PME-ETI face à Shai-Hulud et ses dérivés ne peut plus s’appuyer sur trois piliers historiques qui étaient encore efficaces il y a six mois :
- La détection par signature est neutralisée. Les antivirus traditionnels et les listes de hashs publiées par les éditeurs après chaque incident sont, par construction, en retard d’un build. Un EDR moderne pilotant ses décisions sur le comportement (création de process, accès réseau, mutation système) reste utile ; un AV signature-only ne couvre plus rien.
- La provenance Sigstore ne suffit plus comme signal de confiance. Comme nous l’avions documenté pour TanStack, un attaquant disposant d’un token OIDC GitHub Actions peut générer des attestations Sigstore parfaitement valides pour un paquet malveillant. Le badge « signé » est une présomption, pas une preuve.
- La revue manuelle des dépendances ne passe plus à l’échelle. Avec un framework polymorphique en libre accès, la fréquence des compromissions va dépasser la capacité d’une équipe humaine à les analyser une par une. L’automatisation devient une obligation opérationnelle, pas un confort.
À l’inverse, trois bonnes pratiques deviennent absolument structurantes :
- Le verrouillage des lockfiles avec vérification d’intégrité bloquante (
integritydanspackage-lock.jsonoupnpm-lock.yaml, validation en CI qui casse le build au moindre hash divergent). C’est la seule garantie qui ne dépend pas de l’éditeur. - La segmentation stricte des permissions OIDC dans les workflows CI/CD :
id-token: nonepar défaut, écriture activée uniquement sur le job de publication explicite, avec branches protégées et revue obligatoire. La majorité des compromissions Shai-Hulud passent par ce canal. - Le blocage proactif des canaux d’exfiltration au DNS et au pare-feu. Les variantes connues exfiltrent via réseaux P2P chiffrés (
getsession.org) ou dépôts GitHub jetables. Un filtrage DNS sortant qui n’autorise que les destinations métier connues neutralise l’étape finale, même si le payload s’est exécuté.
L’angle stratégique : pourquoi la souveraineté défensive devient un sujet immédiat
La diffusion du code source Shai-Hulud arrive deux semaines après l’alerte du Campus Cyber sur l’IA offensive et la vague de zero-days attendue dans les trois à six mois (lire notre analyse des 4 chantiers prioritaires pour PME-ETI). Les deux sujets convergent : on assiste à une démocratisation simultanée de l’outillage offensif (IA d’un côté, framework worm de l’autre) qui mécaniquement va comprimer le temps entre divulgation et exploitation. Une PME-ETI qui dépend exclusivement de fournisseurs de sécurité non-européens pour qualifier et répondre à ces menaces se retrouve à la fois en retard d’information (les alertes circulent d’abord en anglais sur Twitter/X) et en dépendance opérationnelle.
La réponse n’est pas de tout réinternaliser, mais de bâtir un socle hybride avec gouvernance européenne. Le couple le plus efficace que nous voyons fonctionner chez nos clients combine une sonde EDR éprouvée (CrowdStrike Falcon pour la profondeur de télémétrie comportementale) et un Agentic SOC ucyber.ai qui ingère cette télémétrie et applique des modèles IA souverains pour qualifier, contextualiser et orienter la réponse en français, sur un dashboard exploitable par un dirigeant non technique. C’est cette architecture — capteur étranger, cerveau IA européen — qui permet à une PME-ETI d’absorber sereinement la vague de variantes Shai-Hulud à venir sans recruter d’équipe SOC interne et sans abandonner le contrôle de la décision.
Conclusion : trois semaines pour passer en posture défensive de nouvelle génération
Le timing imposé par TeamPCP ne nous laisse pas le luxe d’attendre. Avec un framework worm en libre accès, des variantes déjà observées dans la nature et une trajectoire confirmée de plusieurs mutations à venir, la fenêtre utile pour durcir la chaîne logicielle d’une PME-ETI se compte en semaines. La feuille de route minimale pour les vingt prochains jours : audit complet des lockfiles et activation du blocage par intégrité, revue de tous les workflows GitHub Actions avec restriction OIDC, mise en place d’un filtrage DNS sortant strict, et — pour les organisations sans équipe sécurité dédiée — bascule vers un Agentic SOC européen qui absorbera la cadence des nouvelles compromissions sans transformer chaque alerte en incident à gérer. Ceux qui décideront en juin auront déjà encaissé deux ou trois vagues de plus.