La leçon de chaîne d'approvisionnement à tirer de Shai-Hulud et du Mégalodon

En bref

Qu'est-ce que c'est ? Shai-Hulud et Megalodon étaient des attaques de la chaîne d'approvisionnement logicielle survenues en 2026 qui visaient les systèmes auxquels les développeurs font le plus confiance : les registres de paquets, les workflows GitHub Actions, les exécuteurs CI/CD, les pipelines de provenance et la fédération d'identités dans le cloud.

Impact : Mini Shai-Hulud a compromis des paquets npm et PyPI, notamment ceux liés à TanStack, Mistral AI, Guardrails AI, UiPath et OpenSearch. Il s’agit de la première attaque largement documentée à avoir diffusé un logiciel malveillant doté d’une provenance SLSA de niveau 3 valide (CVE-2026-45321, CVSS 9,6). Megalodon a ensuite poussé 5 718 commits malveillants vers 5 561 dépôts GitHub en environ six heures, en introduisant des portes dérobées dans les workflows GitHub Actions afin de voler des identifiants cloud, des clés SSH, des jetons GitHub, des données de jetons OIDC et des secrets liés au code source.

Statut : ces campagnes ne font plus la une de l'actualité, mais la leçon à en tirer reste d'actualité. Tout identifiant exposé, tout workflow compromis et inactif, toute version de paquet piratée ou toute politique de confiance CI/CD trop large qui n'aurait pas été corrigée peut encore présenter un risque en aval.

Gravité : impact important sur la chaîne logistique. Il ne s'agit pas d'un simple paquet vulnérable ni d'un seul CVE que l'on peut corriger et oublier. Il s'agit d'un schéma d'attaque reproductible visant les outils utilisés pour développer et publier des logiciels.

Pourquoi est-ce important pour l'intégration des paquets ? Megalodon a exploité la faille entre le code source et la publication. L’attaquant n’avait pas besoin de compromettre le compte npm, puisqu’un responsable de maintenance légitime pouvait, à son insu, publier à partir d’un code source corrompu. C’est précisément ce type de faille que SecureChain est conçu pour combler, en analysant les nouvelles versions de paquets au moment de leur intégration, notamment les différences de code source, les hooks de compilation, les charges utiles obfusquées, les chemins d’exécution cachés et les comportements d’exfiltration, avant qu’une version ne soit considérée comme fiable en aval.

Agissez dès maintenant : auditez les workflows GitHub Actions, recherchez les indicateurs liés à Megalodon, remplacez les secrets exposés à des exécuteurs CI suspects, passez en revue les paquets importés concernés et renforcez les politiques de confiance OIDC.

Suis-je concerné ?

Vous pourriez être concerné si votre organisation :

• Utilise GitHub Actions pour les compilations, les tests, les mises en production, la publication de paquets ou le déploiement
• Permet aux workflows de demander un jeton d'identification : écriture
• Stocke les identifiants de connexion au cloud, au registre, à SSH, à Docker, à Kubernetes, à Terraform ou à Vault dans l'environnement CI/CD
• Utilise des paquets npm ou PyPI provenant de registres publics sans contrôles supplémentaires à la réception
• Paquets Mini Shai-Hulud concernés installés pendant la fenêtre d'exposition de mai 2026
• Versions 2.18.6 à 2.18.12 de @tiledesk/tiledesk-server installées
• Permet d'effectuer des poussées directes vers les branches par défaut
• Ne nécessite pas de révision pour les modifications apportées à .github/workflows
• Considère la provenance, la signature ou un éditeur de paquets connu comme une garantie de la sécurité d'une dépendance

Pour commencer rapidement, vous pouvez effectuer une recherche dans les référentiels en utilisant les noms connus des workflows Megalodon et l'adresse C2 :

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

Recherchez ensuite les exécutions de shell encodées au sein des workflows :

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

Si l'une ou l'autre de ces recherches révèle des résultats inattendus, consultez l'historique du dépôt et les journaux d'intégration continue avant de supprimer des fichiers ou de renouveler les identifiants. Les journaux peuvent s'avérer nécessaires pour comprendre quelles opérations ont été exécutées, à quel moment et quelles informations confidentielles ont été exposées.

Qu'est-ce que le Shai-Hulud et le Mégalodon ?

Shai-Hulud est le nom donné à une famille d'attaques en chaîne qui se propagent d'elles-mêmes et visent les écosystèmes de développeurs, en particulier npm et PyPI.

Le ver original a fait son apparition en septembre 2025, lorsque l’Unit 42 a identifié un ver npm capable de s’autoreproduire, qui récupérait des identifiants pour les utiliser à des fins de propagation. Une variante plus répandue, Shai-Hulud 2.0, a suivi en novembre. Au printemps 2026, l’acteur malveillant identifié sous le nom de TeamPCP avait passé des mois à implanter des portes dérobées dans des outils de développement et de sécurité hautement fiables.

« Mini Shai-Hulud », la vague de mai 2026, a fait monter les enchères. Elle ne s’est pas contentée de publier des paquets malveillants via des comptes manifestement suspects. Elle a compromis des pipelines de compilation légitimes et les a utilisés pour produire des paquets malveillants accompagnés d’attestations de provenance valides.

Megalodon a visé un autre niveau. Au lieu de se concentrer sur la publication de paquets, il a injecté en masse des workflows GitHub Actions dans des milliers de dépôts. Ces workflows s’exécutaient au sein des runners d’intégration continue (CI) et volaient les secrets que les systèmes CI/CD contiennent par nature : identifiants cloud, jetons GitHub, clés SSH, données de demande de jetons OIDC, identifiants Docker, configurations Kubernetes, identifiants Terraform, jetons Vault et secrets liés au code source.

Prises ensemble, ces deux campagnes révèlent une même évolution. Les pirates ne se contentent plus de tenter de corrompre le paquet que vous installez. Ils cherchent désormais à corrompre le système qui le compile, le signe, le publie et le déploie.

Première vague : le mini Shai-Hulud et le problème du SLSA

Le moment marquant de « Mini Shai-Hulud » s’est produit le 11 mai 2026 à 19 h 20 UTC, lorsque 84 artefacts malveillants ont été publiés dans 42 paquets de l’espace de noms @tanstack en l’espace de six minutes. Ces paquets semblaient provenir du véritable pipeline de publication de TanStack et utilisaient son identité OIDC réelle.

C'est parce qu'ils l'ont fait.

Ce mécanisme, auquel a été attribué le numéro CVE-2026-45321 (CVSS 9,6), enchaînait trois vulnérabilités connues de GitHub Actions en un seul chemin :

1. Un déclencheur « pull_request_target » qui s'exécute avec un accès en écriture même lorsque la pull request qui le déclenche provient d'un fork, ce qui permet d'établir un point d'ancrage.
2. Attaque par « cache poisoning » sur GitHub Actions, utilisée pour introduire une dépendance modifiée dans la compilation légitime.
3. Vol d'un jeton OIDC actif dans la mémoire du processus « runner », utilisé pour obtenir un certificat de signature Sigstore valide.

Grâce à un certificat de signature authentique provenant d’un véritable pipeline, le ver a généré des attestations de provenance SLSA de niveau 3 valides pour les paquets malveillants.

C'est cet aspect qui devrait changer la façon dont les équipes envisagent la traçabilité.

Cela ne signifie pas que SLSA a échoué dans sa mission. Cela signifie simplement que de nombreuses équipes posent à la traçabilité une question à laquelle elle ne peut pas répondre. La traçabilité permet de déterminer d'où provient un artefact et s'il a été généré selon le processus prévu. Dans ce cas précis, cette garantie était techniquement valable, car les paquets malveillants avaient bel et bien été générés par le pipeline prévu. Le problème résidait dans le fait que le pipeline lui-même avait été compromis.

SLSA atteste de l’intégrité de la compilation. Il ne prouve pas que le code intégré à la compilation était sûr, que le workflow n’avait pas été corrompu, ni que l’environnement du responsable de maintenance n’avait pas été compromis en amont. Cette distinction n’est pas purement théorique : la vague d’attaques par imitation du 1er juin visant l’espace de noms @redhat-cloud-services a donné lieu à la diffusion de paquets malveillants, chacun doté d’une provenance npm valide, publiés via GitHub Actions OIDC à partir d’un compte d’employé compromis. La provenance a fait exactement ce qu’elle promet. Mais elle ne garantit pas ce que les équipes supposent.

Le ver s’est propagé à 172 paquets npm ainsi qu’à deux paquets PyPI, à travers 404 versions malveillantes, touchant ainsi les écosystèmes liés à TanStack, Mistral AI, Guardrails AI, UiPath et OpenSearch. La charge utile obfusquée de 2,3 Mo a parcouru plus de 100 chemins d’accès à la recherche de secrets et a installé des mécanismes de persistance résistant au redémarrage dans des outils de développement, notamment Claude Code et Visual Studio Code. Selon les rapports publics, les paquets affectés totalisaient plus de 518 millions de téléchargements [vérifier le chiffre exact avant publication ; les sources divergent quant à savoir s’il s’agit d’un chiffre cumulé ou hebdomadaire], ce qui explique pourquoi il s’agissait d’un problème de dépendance en aval pour toute organisation ayant effectué des téléchargements à partir de registres publics pendant cette période, et non pas simplement d’un incident du côté des mainteneurs.

Un jour plus tard, le 12 mai, TeamPCP a mis en open source l'intégralité du framework Shai-Hulud sur GitHub sous licence MIT, accompagnant apparemment cette initiative d'un concours offrant 1 000 $ en Monero à l'auteur de la plus grande attaque de chaîne d'approvisionnement réalisée à l'aide de cet outil. Une capacité perfectionnée au fil des mois est ainsi devenue, en l'espace d'un week-end, un outil que n'importe quel pirate compétent pouvait reproduire.

Une vérification de provenance « verte » ne constitue pas un gage de sécurité. Il s'agit d'un élément parmi d'autres à prendre en compte dans une décision globale relative à la confiance.

Deuxième vague : le Megalodon et la révolution CI/CD

Six jours après cette publication en open source, Megalodon a fait son apparition.

Entre 11 h 36 et 17 h 48 UTC le 18 mai 2026, les auteurs de cette campagne ont publié 5 718 commits malveillants dans 5 561 dépôts GitHub. L'attaquant a utilisé des comptes jetables dotés de noms d'utilisateur aléatoires de huit caractères (rkb8el9r, bhlru9nr, etc.) et a usurpé l'identité d'auteurs de type « bot » :

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Les messages de commit ont été rédigés de manière à donner l'impression d'une maintenance de routine :

• ci : ajouter une étape d'optimisation de la compilation
• tâche : optimiser le temps d'exécution du pipeline
• des modifications similaires liées à l'interface utilisateur, que l'on a tendance à ne pas remarquer

L'attaquant ne cherchait pas à faire passer le code de l'application pour du code malveillant. Il cherchait plutôt à faire passer les modifications apportées au pipeline pour des opérations banales.

Megalodon a déployé deux variantes de workflow GitHub Actions, qui demandaient toutes deux les autorisations « id-token: write » et « actions: read », exécutaient toutes deux une charge utile Bash décodée en base64 et communiquaient toutes deux avec le même serveur C2 à l'adresse 216.126.225.129:8443.

SysDiag était la variante la plus bruyante et la plus généralisée. Elle ajoutait un workflow déclenché à chaque requête de push et de pull, ce qui maximisait la fréquence de son exécution et de sa collecte de données.

Optimize-Build était la variante silencieuse. Elle utilisait `workflow_dispatch`, ce qui permettait au workflow de rester inactif jusqu’à ce qu’il soit déclenché manuellement via l’API GitHub. Cela la rendait d’autant plus utile comme « porte dérobée » : pas d’échecs constants de compilation, pas de dysfonctionnement flagrant, et aucune raison immédiate pour qu’un responsable de maintenance s’en aperçoive.

La collecte de données par le payload était très étendue. Il a recueilli les variables d’environnement CI et le répertoire /proc/*/environ, les identifiants AWS de tous les profils configurés, les jetons Google Cloud, les identifiants de rôle d’instance extraits des points de terminaison AWS IMDSv2 et Azure IMDS, les clés privées SSH, les identifiants Docker, .npmrc, .netrc, Kubernetes, Vault et Terraform, l’historique du shell, plus de 30 modèles d’expressions régulières correspondant à des clés API et des chaînes de connexion, et, surtout, l’URL de demande de jeton OIDC de GitHub Actions ainsi que le jeton correspondant, en plus des jetons GITHUB_TOKEN, GitLab et Bitbucket.

Pourquoi le vol de l'OIDC est-il important ?

De nombreuses organisations ont abandonné l'utilisation de clés cloud à longue durée de vie dans leurs processus CI/CD au profit de la fédération OIDC. C'est une bonne évolution. Au lieu de stocker des identifiants permanents AWS, Google Cloud ou Azure dans GitHub Actions, le workflow demande des identifiants à courte durée de vie lorsqu'il en a besoin.

Megalodon montre en quoi ce modèle doit encore être encadré.

Si un workflow malveillant est en mesure de demander un « id-token : write », il peut obtenir les données de demande de jeton OIDC nécessaires pour usurper l'identité d'un workflow de confiance. Si la portée de la politique de confiance cloud correspondante est trop large, ce workflow malveillant peut générer des identifiants cloud à durée de vie limitée sur la propre machine de l'attaquant.

Le problème n'est pas que l'OIDC soit mauvais. Le problème, c'est que la confiance OIDC doit être restreinte. Une configuration sécurisée devrait répondre aux questions suivantes :

• Quel référentiel précis peut demander ce rôle ?
• Quelle branche, quel tag ou quel environnement est autorisé ?
• Quel processus est autorisé ?
• Ce workflow a-t-il réellement besoin de la fonction « id-token : write » ?
• Un workflow nouvellement ajouté peut-il hériter du même niveau de confiance ?
• Un workflow situé sur une branche qui n'est pas une branche de mise en production peut-il demander des identifiants d'accès à l'environnement de production ?

Si la politique de confiance stipule en substance que « ce référentiel est fiable », le périmètre d'impact est plus large qu'il ne devrait l'être. L'OIDC réduit le risque lié aux secrets statiques de longue durée. Il ne résout toutefois pas le problème de l'exécution de workflows corrompus.

L'affaire Tiledesk met en évidence les risques en aval

Le problème du Megalodon ne concernait pas uniquement le propriétaire du référentiel.

Au moins un paquet en aval, @tiledesk/tiledesk-server, a été publié sous une forme corrompue dans les versions 2.18.6 à 2.18.12. Il est important de noter que le compte npm n'était pas le point d'entrée initial de l'attaque. Le pirate a corrompu le dépôt source en y injectant des fichiers de workflow GitHub Actions malveillants, et le responsable légitime a ensuite publié, à son insu, des versions issues de cette source corrompue.

C'est pourquoi l'authentification à deux facteurs (2FA) et la signature de code n'étaient pas suffisantes. L'événement de publication semblait toujours légitime, car l'attaquant n'a jamais eu besoin de prendre le contrôle du compte npm. Ces deux mesures de sécurité confirmaient que la version provenait bien du véritable responsable du projet, ce qui était effectivement le cas. La faille d'intégrité se situait en amont, entre le code source et la publication.

C’est également pour cette raison que l’analyse des différences de code source revêt une importance particulière. Un détecteur qui compare une nouvelle version d’un paquet à sa version précédente au moment de son intégration examinerait les modifications apportées entre les versions 2.18.5 et 2.18.6 avant de valider la nouvelle version. Les fichiers de workflow et la charge utile injectés entrent clairement dans les catégories susceptibles de déclencher des alertes : hooks d’exécution au moment de la compilation, chemins d’exécution de type CI/CD, charges utiles obfusquées, exécution cachée, collecte d’identifiants et activité réseau suspecte — soit le même type de porte dérobée que « event-stream » et « ua-parser-js ».

C'est précisément cette lacune que SecureChain a été conçu pour combler. En analysant le diff source plutôt qu'en se fiant à l'événement de publication, SecureChain est conçu pour détecter le scénario dans lequel un responsable de maintenance publie un code source corrompu — scénario que la signature, la traçabilité et l'authentification à deux facteurs (2FA) via le registre ne parviennent pas à détecter — et pour fournir à l'équipe de sécurité un artefact d'analyse, des segments de diff signalés, une justification et un verdict, avant que la version ne soit diffusée en aval.

 

Voici à quoi ressemble la cascade dans son ensemble :

1. Un référentiel est modifié à la suite d'un accès non autorisé ou détourné.
2. Un workflow GitHub Actions est injecté ou remplacé.
3. Le workflow s'exécute au sein d'un environnement CI sécurisé.
4. Les secrets sont récoltés auprès du coureur.
5. Un paquet peut être compilé ou publié à partir d'un code source corrompu.
6. Les utilisateurs en aval installent ce qui semble être un logiciel légitime.

Du point de vue du consommateur, le nom du paquet est familier, l'éditeur est légitime et la publication provient du compte attendu. Mais la source et le processus qui se cachent derrière avaient déjà été compromis. « Éditeur de confiance » et « paquet sûr » ne sont pas synonymes.

La polémique sur l'attribution, et pourquoi cela ne change rien à votre réponse

C'est là que la couverture médiatique devient confuse.

TeamPCP est étroitement lié à l'activité plus large de Shai-Hulud, notamment aux précédentes campagnes visant la chaîne d'approvisionnement et à la publication, le 12 mai, du framework de ver informatique. Certains rapports attribuent directement Megalodon à TeamPCP.

Une lecture plus attentive révèle que Megalodon présente de fortes similitudes techniques avec les activités de type Shai-Hulud, mais l’attribution directe n’est pas établie. OX Security, qui a analysé la charge utile de Megalodon, a estimé qu’il s’agissait très probablement d’une imitation, soulignant un comportement et un style similaires, mais peu de code commun, l’absence de liens directs, d’indicateurs d’identification partagés et de revendication de responsabilité. Megalodon ne dispose pas non plus de la clé de chiffrement publique exigée par TeamPCP pour participer à son propre concours ; il ne s’agit donc même pas d’une candidature au concours. Mini Shai-Hulud présente des indices forts permettant de l’attribuer à TeamPCP ; Megalodon présente des similitudes indirectes. Considérez l’attribution directe comme peu fiable.

Pour les responsables de la sécurité, cette distinction ne doit pas ralentir les actions. Que Megalodon soit TeamPCP, un imitateur ou un autre acteur utilisant des outils open source, la réponse est la même : rechercher les workflows compromis, renouveler les secrets exposés, renforcer l’OIDC, restreindre les modifications des workflows et considérer les terminaux des développeurs ainsi que les identités CI/CD comme faisant partie intégrante de la chaîne d’approvisionnement. Il faut se prémunir contre la méthode, et non contre le nom de la marque.

La cause profonde est également moins exotique que ne le laissent supposer les noms de ces campagnes. Hudson Rock a recoupé les noms d’utilisateur GitHub associés aux commits de Megalodon avec sa base de données d’infostealers et a constaté que 331 sur 978 (plus d’un tiers) correspondaient à des machines déjà infectées par des infostealers, ce qui lui a permis de conclure que l’accès provenait des journaux d’infostealers. La condition préalable à des attaques de ce type n’est généralement pas une faille « zero-day » sur GitHub. Il s’agit plutôt d’un poste de travail de développeur ou d’un environnement de maintenance qui avait déjà été compromis.

Pourquoi les scanners traditionnels ne détectent pas ce type d'attaque

La plupart des outils d'analyse de vulnérabilités sont conçus pour répondre à des questions telles que :

• Ce paquet fait-il l'objet d'un CVE connu ?
• Cette dépendance est-elle obsolète ?
• Ce conteneur utilise-t-il une bibliothèque vulnérable ?
• Cet artefact est-il associé à un logiciel malveillant connu ?

Ces questions restent d'actualité. Mais Shai-Hulud et Megalodon évoluent à un tout autre niveau.

Un workflow GitHub Actions corrompu ne correspond pas nécessairement à une dépendance vulnérable. Une charge utile de type shell encodée en base64 dans le répertoire .github/workflows peut ne pas apparaître dans une SBOM. Un jeton OIDC volé n’est pas un CVE. Un paquet malveillant peut présenter une provenance valide si le pirate a compromis le pipeline qui l’a généré. Un responsable de maintenance légitime peut publier une version malveillante si la source à partir de laquelle il effectue la publication a déjà été corrompue.

La sécurisation de la chaîne logistique doit aller au-delà du produit final. Les équipes ont besoin de contrôles permettant de vérifier :

• Comportement du paquet avant l'installation
• modifications au niveau du code source et différences entre les versions
• intégrité du flux de travail et hooks d'exécution au moment de la compilation
• Autorisations CI/CD et comportement des runners
• provenance et contexte d'attestation
• champ d'application de l'identité dans le cloud
• Exposition des identifiants des responsables de maintenance et des développeurs
• signaux de vulnérabilité et de compromission post-publication

Le registre n'est qu'une couche parmi d'autres. Le système de compilation est désormais une cible prioritaire.

Atténuation

Considérez Shai-Hulud et Megalodon comme une occasion de passer au crible et de renforcer la chaîne de livraison logicielle, surtout si vous n’avez pas réévalué votre exposition aux risques liés à la CI/CD depuis mai 2026.

1. Parcourez vos dépôts

Rechercher dans les dépôts et les forks GitHub :

• Noms des workflows « SysDiag » et « Optimize-Build »
• l'adresse C2 216.126.225.129
• Exécution de la commande « base64 -d | bash »
• déclenchements inattendus de `workflow_dispatch`
• jeton d'identification inexpliqué : droits d'écriture
• commits de workflow provenant d'identités inconnues ressemblant à des bots
• poussées directes ayant modifié .github/workflows

Prêtez une attention particulière aux modifications apportées aux processus de travail aux alentours du 18 mai 2026, notamment celles qui ont contourné la procédure de révision des pull requests.

2. Bloquer et examiner les voies de sortie connues

Bloquez le trafic sortant provenant des runners CI vers l'adresse 216.126.225.129:8443, et examinez l'historique des journaux du proxy, du pare-feu et de NetFlow pour détecter les connexions provenant des systèmes de compilation ou des runners auto-hébergés. Le blocage de cette adresse IP ne constitue pas une protection totale, car l'infrastructure évolue rapidement, mais il s'avère utile pour l'analyse rétrospective et le nettoyage immédiat.

3. Renouveler les secrets exposés

Si un workflow suspect a été exécuté, partez du principe que l'environnement du runner a été compromis. Donnez la priorité à la rotation des PAT GitHub et des jetons granulaires, des clés de déploiement, des secrets Actions, des identifiants des applications GitHub, des jetons de publication npm et PyPI, des identifiants des registres Docker, des clés privées SSH, des identifiants AWS, Google Cloud et Azure, des configurations Kubernetes, des identifiants Terraform, des jetons Vault et des relations de confiance OIDC liées aux workflows concernés.

Une mise en garde avant de procéder à la révocation : certaines charges utiles de la famille Shai-Hulud intègrent un mécanisme de sécurité destructeur lié à la révocation des jetons. Ce comportement n’est pas confirmé comme étant une fonctionnalité des charges utiles Megalodon, mais pour tout hôte que vous soupçonnez d’être infecté, isolez-le et effectuez une image de celui-ci, puis conservez les journaux CI, l’historique d’exécution des workflows et les événements d’audit avant de révoquer les identifiants.

4. Mettre en quarantaine les versions de paquets dont on sait qu’elles sont compromises

Si vous utilisez @tiledesk/tiledesk-server, vérifiez si les versions 2.18.6 à 2.18.12 sont présentes. Si l'une d'entre elles a été installée, compilée ou déployée, passez en revue les environnements concernés et mettez à jour les secrets utilisés lors de la compilation ou de l'exécution. Restez sur la dernière version vérifiée et sans faille, à savoir la 2.18.5, et validez les fichiers de verrouillage.

5. Renforcer la confiance dans l'OIDC

N’accordez pas de confiance générale au niveau du dépôt pour les rôles cloud sensibles. Dans la mesure du possible, limitez la confiance OIDC par dépôt, branche, balise, environnement, fichier de workflow, public et chemin de publication. Une condition telle que « sub restricted to repo:org/name:ref:refs/heads/main » empêche un workflow malveillant sur une branche secondaire de générer des identifiants de production.

Passez en revue tous les flux de travail qui demandent :

permissions:
id-token: write

Supprimez-le, sauf si le workflow justifie de manière documentée la nécessité de demander un jeton.

6. Exiger une validation en cas de modification du flux de travail

Considérez le répertoire .github/workflows comme du code sensible sur le plan de la sécurité. Veillez à ce que les fichiers de workflow soient approuvés par les CODEOWNERS, à ce que les branches soient protégées, à ce que les pull requests fassent l’objet d’une révision obligatoire, à ce que les commits soient signés le cas échéant, à ce que les autorisations par défaut pour les Actions soient en lecture seule, à ce que les actions tierces soient associées à des SHA de commit plutôt qu’à des balises modifiables, à ce que le trafic sortant des runners soit restreint, et à ce que des runners distincts soient utilisés pour les workflows de publication sensibles. Un fichier de workflow peut être aussi puissant que du code de déploiement en production. Il ne devrait pas être plus facile à modifier.

Détection

Aucun résultat d'analyse ne prouve à lui seul l'exposition à Shai-Hulud ou à Megalodon. Les preuves pertinentes se trouvent dans l'historique des référentiels, les fichiers de workflow, les journaux des exécutions CI, les journaux réseau, les événements d'audit GitHub, les journaux d'identité cloud et les fichiers de verrouillage des paquets. Les signaux comportementaux ont également une durée de vie plus longue que les indicateurs atomiques, car l'opérateur renouvelle régulièrement l'infrastructure.

Parmi les signaux utiles, on peut citer :

• modifications inattendues dans .github/workflows
• Exécution d'un shell décodé en base64 au sein de l'environnement CI
• flux de travail « workflow_dispatch » nouveaux ou inexpliqués
• flux de travail demandant un jeton d'identification : écriture sans raison valable
• poussées directes vers les branches par défaut
• des noms d'auteurs inhabituels, ressemblant à ceux de bots, et des dates de commit falsifiées
• trafic sortant du CI Runner vers l'adresse 216.126.225.129
• nouvelles clés de déploiement, autorisations OAuth ou installations d'applications GitHub
• hypothèses inhabituelles concernant le rôle du cloud issues des identités GitHub Actions
• publier les paquets peu après des modifications suspectes du flux de travail
• versions inattendues de npm ou PyPI dans les fichiers de verrouillage provenant de la fenêtre d'exposition

Exemples de termes de recherche sur GitHub :

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

Exemple de recherche de workflow local :

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

Ces contrôles constituent un point de départ, et non un certificat de bonne santé.

Liste de contrôle des mesures correctives prioritaires

Vérifier les dépôts : passer en revue les modifications apportées aux workflows GitHub Actions, en particulier celles effectuées aux alentours du 18 mai 2026.

Recherche des indicateurs de compromission (IOC) : recherchez SysDiag, Optimize-Build, toute exécution suspecte de base64 et l'adresse C2 signalée.

Conserver les journaux : conservez les journaux d'exécution des workflows, les journaux d'audit GitHub, les fichiers de verrouillage des paquets et les artefacts de compilation avant le nettoyage.

Rotation des secrets : effectuez la rotation des identifiants exposés à tout environnement d'exécution suspect.

Renforcer l'OIDC : limiter la portée des politiques de confiance dans le cloud à des flux de travail, des branches, des balises ou des environnements spécifiques.

Limiter les modifications apportées aux workflows : exiger l'examen des pull requests et l'approbation des CODEOWNERS pour les fichiers .github/workflows.

Vérification des paquets installés : vérifiez si des versions de paquets connues pour être compromises ont été installées dans votre environnement.

Renforcer le CI/CD : associer les actions tierces aux SHA des commits, limiter le trafic sortant des runners et réduire au minimum les autorisations par défaut des workflows.

Inspecter les points d'accès des développeurs : considérer les postes de travail des développeurs comme faisant partie de la chaîne logistique, en particulier lorsque les responsables de la maintenance ont installé des paquets concernés ou disposaient d'identifiants stockés localement.

Pourquoi cela va bien au-delà d'une simple campagne

Ce qui importe concernant Shai-Hulud et Megalodon, ce n’est pas seulement leur ampleur. C’est leur direction d’attaque. Les attaquants progressent en amont, depuis des entités vulnérables vers les systèmes de confiance situés en arrière-plan :

• identifiants du responsable de la maintenance
• points de terminaison pour développeurs
• Exécuteurs CI/CD
• Workflows GitHub Actions
• Identités OIDC
• automatisation de la publication de paquets
• systèmes de provenance et de signature
• rôles liés au déploiement dans le cloud

Cela redéfinit ce que doit signifier la sécurité open source. Il ne suffit plus d’analyser un paquet une fois qu’il a été intégré à votre environnement. Vous devez savoir d’où il provient, comment il a été compilé, si le processus de compilation était fiable, ce qui a changé par rapport à la version précédente, si le paquet effectue des actions suspectes lors de l’installation ou de la compilation, si l’éditeur ou le dépôt a été compromis, et si le composant continuera à bénéficier de correctifs de sécurité après son déploiement.

C’est précisément le problème que SecureChain a été conçu pour résoudre. SecureChain offre aux organisations une source fiable de composants open source, avec un filtrage des logiciels malveillants, une inspection au niveau du code source, la traçabilité de la provenance et la correction continue des vulnérabilités CVE tout au long du cycle de vie des composants. Pour les nouvelles versions de paquets, la solution est conçue pour analyser les différences d’une version à l’autre et signaler les modifications suspectes avant qu’elles ne soient considérées comme fiables en aval, notamment les hooks d’exécution au moment de la compilation, les charges utiles obfusquées, les chemins d’exécution cachés et les comportements d’exfiltration.

Dans un scénario de type « Megalodon », cela a son importance car le paquet peut être publié par le responsable légitime depuis son compte légitime. La modification malveillante ne se situe pas au niveau du registre. Elle se trouve dans le code source corrompu qui a été transmis au registre.

Shai-Hulud et Megalodon nous rappellent que la chaîne d'approvisionnement logicielle ne se limite pas au code que l'on installe. Il s'agit du système qui l'a sélectionné, développé, signé, publié et qui continue de le maintenir. Ce système doit désormais être sécurisé au même titre que l'infrastructure de production.

Découvrez SecureChain →

FAQ

Le Mégalodon, c'est la même chose que Shai-Hulud ?

Non. Shai-Hulud désigne une famille d’attaques auto-propagatrices visant la chaîne d’approvisionnement, notamment via npm et PyPI. Megalodon était une campagne massive d’injection de workflows dans GitHub Actions qui a eu lieu le 18 mai 2026. Ces deux opérations sont liées par leur chronologie et leurs techniques, mais il n’est pas confirmé que Megalodon soit la même opération ou le même opérateur.

Le projet « Megalodon » a-t-il bel et bien été mené à bien par TeamPCP ?

Non. TeamPCP est étroitement lié à l'activité de Shai-Hulud qui l'entoure, et Megalodon présente des similitudes avec ce type d'attaque, mais aucun lien direct n'a été confirmé. Les chercheurs qui ont analysé le code de Megalodon estiment qu'il s'agit très probablement d'un imitateur. Les responsables de la sécurité devraient se concentrer sur la technique plutôt que sur l'identité de l'acteur.

La provenance SLSA me protège-t-elle contre cela ?

Pas en soi. Mini Shai-Hulud a démontré que des paquets malveillants peuvent comporter une provenance SLSA de niveau 3 valide si l'attaquant parvient à compromettre le pipeline de compilation. La provenance permet de prouver l'origine et l'intégrité de la compilation. Elle ne prouve pas que le code était sûr.

L'OIDC permet-il de protéger le CI/CD contre le vol d'identifiants ?

L'OIDC est plus sûr que le stockage de clés cloud à longue durée de vie dans l'infrastructure en continu (CI), mais il nécessite tout de même une définition rigoureuse du périmètre d'application. Si un workflow malveillant peut demander un « id-token : write » et que la politique de confiance du cloud est trop large, un attaquant peut générer des identifiants à courte durée de vie via l'identité du pipeline de confiance.

Pourquoi l'authentification à deux facteurs (2FA) et la signature n'ont-elles pas empêché la compromission de Tiledesk ?

En effet, l'attaquant n'a pas eu besoin de pirater le compte npm. Megalodon a corrompu le dépôt source, et le responsable légitime a effectué la publication à partir de cette source corrompue. L'authentification à deux facteurs (2FA) et la signature protègent l'opération de publication ; elles ne garantissent pas pour autant que la source publiée était intacte.

Je ne gère pas beaucoup de dépôts GitHub. Suis-je quand même exposé à des risques ?

C'est possible. Même si vous n'avez pas été directement touché, vos dépendances en amont ont peut-être été compilées ou publiées à partir de dépôts compromis. Toute organisation qui utilise des paquets open source hérite d'une partie du risque lié aux pipelines de compilation qui sous-tendent ces paquets.

Quelle est la solution la plus importante à long terme ?

Considérez le CI/CD comme une infrastructure de production. Limitez les modifications apportées aux workflows, définissez strictement le périmètre de l’OIDC, surveillez le comportement des runners, réduisez le nombre de secrets dans le CI, inspectez les paquets avant leur installation et cessez de considérer la provenance ou un éditeur connu comme un gage de sécurité absolu.

Sources

• Cloud Security Alliance – « Shai-Hulud/Megalodon : une attaque en deux vagues visant la chaîne d'approvisionnement des développeurs via l'IA »
• Protos Labs – « La campagne Shai-Hulud de TeamPCP et la vague d’imitateurs »
• SafeDep – Analyse de la campagne « Megalodon » (ensemble de données « commit », cascade Tiledesk)
• OX Security – Analyse de l'attribution des imitations de Megalodon et Shai-Hulud
• StepSecurity – Analyse de l'exfiltration de secrets dans Megalodon GitHub Actions ; analyse de Mini Shai-Hulud / TanStack
• Tenable – Mini Shai-Hulud CVE-2026-45321 : Foire aux questions
• Hudson Rock – Analyse des causes profondes de l'attaque par le logiciel de vol d'informations « Megalodon »
• Unit 42 (Palo Alto Networks) – premier signalement du ver Shai-Hulud, septembre 2025
• The Hacker News – Couverture de la campagne « Megalodon » et « Mini Shai-Hulud »
• Socket – Invalidation des jetons npm et analyse de la campagne Shai-Hulud