prt-scan : 500 PR malveillantes pilotées par IA sur GitHub

Les faits

Wiz Research a publié le 28 avril 2026 une analyse détaillée d'une campagne de supply chain visant GitHub, baptisée prt-scan. L'opération, attribuée à un acteur unique opérant principalement sous le compte ezmtebo, a démarré le 11 mars 2026 — soit trois semaines avant qu'elle ne soit publiquement identifiée par le chercheur Charlie Eriksen le 2 avril. Six vagues distinctes ont été observées par Wiz, qui a consolidé l'attribution sur la base de signatures comportementales communes.

Le mode opératoire repose entièrement sur l'abus du déclencheur pull_request_target dans les workflows GitHub Actions. Contrairement à pull_request, ce trigger exécute le code du workflow avec les secrets du dépôt cible, ce qui en fait une cible privilégiée pour exfiltrer des credentials lorsque la PR provient d'un fork malveillant. L'attaquant a ouvert plus de 475 PR malveillantes en 26 heures sur la dernière vague seule, en visant aussi bien des organisations majeures que des projets hobbyistes.

Chaque PR contenait un payload en cinq phases. Phase 1 : extraction des variables d'environnement disponibles dans le runner. Phase 2 : scan ciblé pour détecter des secrets à forte valeur (clés AWS, tokens Cloudflare API, credentials Netlify, tokens npm). Phase 3 : tentatives de contournement des labels de sécurité GitHub. Phase 4 : exécution de processus en arrière-plan pour capter les credentials injectés par les étapes CI suivantes. Phase 5 : exfiltration vers une infrastructure C2 contrôlée par l'attaquant.

Le bilan technique est préoccupant. Sur plus de 450 tentatives analysées par Wiz, le taux de succès reste inférieur à 10 %. Mais les compromissions effectives ont permis d'exfiltrer des secrets de 50 dépôts au moins, dont des clés cloud actives. Deux packages npm ont été compromis avec succès. Les cibles à forte valeur — Sentry, OpenSearch, IPFS, NixOS, Jina AI, recharts — ont toutes bloqué l'attaque grâce à une combinaison de protections : approbation manuelle des contributeurs externes, restrictions par actor, et conditions de déclenchement basées sur les chemins modifiés.

L'élément qui transforme cette campagne en signal faible majeur est l'usage massif de l'intelligence artificielle. Plusieurs caractéristiques pointent vers une orchestration assistée par LLM. La vélocité d'abord : environ 7 PR par heure soutenus pendant plus de 22 heures, ce qui dépasse largement la cadence d'un opérateur humain. Le ciblage adaptatif ensuite : le payload identifie dynamiquement le langage, le framework, le test runner et la configuration CI du dépôt avant d'adapter sa charge utile. Enfin, l'idiomaticité du code généré : les payloads s'intègrent dans la convention du projet ciblé, qu'il s'agisse de structures de tests Go, de patterns conftest pytest ou de hooks npm scripts.

Cette industrialisation représente un saut qualitatif. Les anciennes campagnes de prt-scan utilisaient des scripts bash bruts identiques sur tous les dépôts. Les vagues les plus récentes utilisent des payloads générés à la volée, contextualisés au point qu'ils peuvent passer inaperçus dans une revue rapide. Wiz indique que cette adaptation contextuelle est probablement le résultat d'un pipeline mixant un scraper de métadonnées de dépôt et un appel à un modèle de langage pour produire le code malveillant final.

L'attaque n'est pas isolée. Elle s'inscrit dans une vague plus large de campagnes supply chain observées en avril 2026, dont CanisterSprawl sur npm et la compromission Checkmarx KICS sur Docker Hub. Le point commun : l'utilisation systématique d'IA pour personnaliser, accélérer et passer sous les radars des défenses statiques. Les défenses traditionnelles fondées sur des signatures ou des règles statiques deviennent insuffisantes face à des charges utiles générées dynamiquement.

Impact et exposition

Toute organisation utilisant pull_request_target dans ses workflows GitHub Actions sans contrôles d'approbation pour les contributeurs externes est potentiellement exposée. Le risque concerne particulièrement les dépôts open source acceptant des contributions sans approbation préalable systématique. Les credentials qui transitent via les runners GitHub-hosted incluent souvent des tokens à fort impact : clés cloud, secrets API, tokens de publication de packages.

L'exposition réelle dépend de la configuration des secrets. Les organisations qui isolent leurs secrets de production dans des environnements GitHub Environments avec règles d'approbation manuelle réduisent l'impact à des credentials périphériques. À l'inverse, les configurations qui injectent les secrets de production directement dans les workflows liés aux PR exposent l'ensemble de la chaîne de déploiement.

Recommandations

• Auditer immédiatement les workflows GitHub Actions pour identifier l'usage de pull_request_target et le restreindre aux cas strictement nécessaires.
• Activer le paramètre Require approval for first-time contributors dans les paramètres Actions de chaque dépôt et organisation.
• Migrer les secrets sensibles vers GitHub Environments avec règles d'approbation manuelle pour les déploiements.
• Utiliser l'outil rapidfort/gh-action-security-audit ou équivalent pour scanner l'organisation à la recherche de configurations à risque.
• Réviser tous les workflows ayant des permissions write-default sur GITHUB_TOKEN et appliquer le principe du moindre privilège.