Enregistrement CVE : https://www.cve.org/CVERecord?id=CVE-2026-44590

Ce dépôt contient la preuve de concept pour CVE-2026-44590, une injection de commande dans le workflow GitHub Actions validate_modified_targets.yml de sherlock-project/sherlock. N'importe quel utilisateur GitHub peut ouvrir une pull request qui déclenche l'exécution arbitraire de commandes dans le contexte CI privilégié, exfiltrer le GITHUB_TOKEN du workflow et auto-approuver la PR malveillante, le tout sans aucune interaction humaine.

Pour l'analyse technique complète (analyse de la cause racine, déroulement de l'exploitation, discussion sur l'impact et un chapitre sur ce qu'un attaquant pourrait faire dans des scénarios réels), consultez l'article de blog :

nstsec.com/en/posts/sherlock-rce-pull-request-target-cve-2026-44590

Ce README se concentre exclusivement sur le script PoC : ce qu'il fait, comment l'exécuter et à quoi s'attendre.

À propos de poc.py

poc.py est un script Python autonome unique (stdlib uniquement) qui automatise toute la chaîne d'attaque de bout en bout :

• fork sherlock-project/sherlock si nécessaire
• (optionnellement) ramène le master du fork au commit précédant le correctif afin que le bug puisse être reproduit même après le correctif en amont
• lance un écouteur OAST (interactsh-client)
• crée et pousse une branche de PR malveillante
• déclenche le workflow vulnérable
• extrait le GITHUB_TOKEN du rappel OAST (en --mode exfil) et le décode en clair
• utilise le jeton volé pour auto-approuver la même PR via l'API GitHub
• affiche un verdict final clair : VULNERABILITY CONFIRMED ou FIX VERIFIED
• nettoie après lui-même (supprime la branche PoC, termine interactsh-client)

Il y a exactement une étape manuelle requise (cliquer sur la bannière « I understand my workflows » de GitHub la première fois par fork), car aucune API publique ne permet de la faire disparaître. Le script détecte ce cas et fait une pause avec une invite claire.

Démarrage rapide

Vérifier que le correctif en amont fonctionne (comportement par défaut)

Fork le dépôt (si nécessaire), synchronise avec l'amont (master corrigé), ouvre une PR malveillante, exécute la chaîne d'attaque et rapporte FIX VERIFIED car le workflow corrigé bloque la charge utile avant qu'aucune commande shell ne s'exécute.

Reproduire la vulnérabilité d'origine

Identique à ci-dessus, mais ramène d'abord le master du fork au commit précédant le correctif (271608fb). Verdict attendu : VULNERABILITY CONFIRMED.

Démontrer l'impact complet (exfiltration du jeton + auto-approbation de la PR)

La charge utile d'exfiltration envoie git config --list à l'OAST et dort pendant 180 secondes pour maintenir le workflow (et donc le GITHUB_TOKEN) actif. Pendant que le workflow dort, le script extrait le jeton du journal OAST, le décode et appelle immédiatement l'API GitHub pour approuver la PR. La PR se retrouve approuvée par github-actions[bot].

Prérequis

• Python 3.8+ (aucune dépendance tierce, uniquement la stdlib)
• gh (GitHub CLI), authentifié :
  root@kitploit:~

  gh auth login
  

• git
• interactsh-client (optionnel mais recommandé). Lorsqu'il est installé, le script le lance automatiquement et vérifie le rappel dans le script :
  root@kitploit:~

  go install github.com/projectdiscovery/interactsh/cmd/interactsh-client@latest
  

  Si vous préférez utiliser votre propre point de terminaison OAST (Burp Collaborator, oast.fun via l'interface web, requestbin, etc.), transmettez-le avec --oast-url et l'étape de vérification automatique sera ignorée.

Le script ne nécessite pas qu'un fork existe au préalable, il en crée un automatiquement.

Modes

--mode harmless (par défaut)

La charge utile est un seul POST curl avec une chaîne de confirmation statique. Aucun secret n'est lu, aucun appel API n'est effectué, le seul effet secondaire est le rappel OAST. Utilisez ce mode pour confirmer que la vulnérabilité existe sans exposer aucune information d'identification.

--mode exfil

La charge utile envoie git config --list (qui contient le GITHUB_TOKEN encodé en base64 sous http.https://github.com/.extraheader) à l'OAST, puis dort pendant 180 secondes. Le script ensuite :

1. Interroge le journal OAST jusqu'à ce que le dump arrive.
2. Extrait le blob base64 avec une expression régulière.
3. Le décode et affiche l'information d'identification en clair : x-access-token:ghs_XXXXXXXX....
4. Supprime le préfixe x-access-token: et utilise le jeton brut pour appeler POST /repos/<fork>/pulls/<n>/reviews avec la charge utile d'approbation standard ({"event":"APPROVE","body":"All checks passed. LGTM!"}).
5. La PR apparaît comme approuvée par github-actions[bot], impossible à distinguer d'une automatisation CI légitime.

Une fois l'approbation enregistrée, le script ignore le reste de la période de sommeil de 180 secondes du workflow, car la chaîne d'attaque est terminée et attendre que le runner expire n'apporte rien.

Options

Pourquoi la PR cible le fork, et non le dépôt en amont

Par conception, le PoC ouvre la PR depuis une branche du fork vers le master du même fork. Il ne cible pas directement sherlock-project/sherlock. Il y a deux raisons à cela.

1. Éviter la divulgation publique d'un exploit

Une pull request sur un dépôt public est visible par tout le monde. Le diff reste indexé même après la fermeture de la PR, et les journaux GitHub Actions sont accessibles via l'interface web. Ouvrir une PR avec une charge utile d'injection de commande fonctionnelle sur le dépôt en amont publierait effectivement un exploit fonctionnel avant que les mainteneurs aient eu la chance de publier un correctif. Toute personne surveillant le dépôt pourrait copier la charge utile, remplacer le rappel OAST par un point de terminaison malveillant et l'utiliser pour exfiltrer le vrai GITHUB_TOKEN.

Le PoC utilise une PR de fork à fork pour garder l'exploit hors de la vue du public tout en démontrant le bug de bout en bout.

2. Reproduire le comportement vulnérable exact

Lorsque vous forkez sherlock-project/sherlock, le fichier de workflow validate_modified_targets.yml est inclus dans le fork. Ouvrir une PR ciblant le master du fork déclenche le workflow dans le contexte du fork, avec un GITHUB_TOKEN émis pour le fork. Les mécanismes sont identiques à l'attaque d'origine :

• Le déclencheur pull_request_target se déclenche automatiquement
• Le workflow s'exécute dans le contexte du dépôt de base (dans ce cas, le fork)
• Le workflow a accès à son propre GITHUB_TOKEN
• actions/checkout écrit le jeton dans .git/config via le paramètre http.https://github.com/.extraheader
• La charge utile injectée peut extraire ou utiliser le jeton

La seule différence est le rayon d'impact : le jeton appartient au fork, pas à sherlock-project/sherlock. La vulnérabilité est reproduite ; l'impact est contenu.

L'unique étape manuelle

GitHub désactive les Actions sur les forks fraîchement créés derrière une bannière d'interface :

Workflows aren't being run on this forked repository Because this repository contained workflow files when it was forked, we have disabled them from running on this fork. Make sure you understand the configured workflows and their expected usage before enabling Actions on this repository.

Il n'existe aucune API publique pour faire disparaître cette bannière. Le script détecte cette condition (fork tout juste créé OU zéro exécution de workflow historique) et fait une pause avec une invite claire :

Après avoir cliqué sur la bannière une fois sur un fork donné, le script ne demandera plus lors des exécutions suivantes contre le même fork.

Exemple de sortie (vulnérable, mode exfil)

Exemple de sortie (corrigé, mode exfil)

Avertissement

Ce dépôt est publié uniquement à des fins éducatives et de recherche en sécurité. La vulnérabilité a été divulguée de manière responsable aux mainteneurs, corrigée en amont, et un CVE a été demandé. N'exécutez pas ce PoC contre des dépôts que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester. L'auteur n'est pas responsable de toute utilisation abusive.

Licence

MIT