pull_request_target : la vuln GitHub Actions que 60% des repos publics ont encore

pull_request_target est un déclencheur GitHub Actions qui existe depuis 2020, documenté, légitime, et largement mal compris. C'est aussi le vecteur exploité dans l'attaque Shai-Hulud de mai 2026 sur TanStack et, par chaîne, sur Mistral AI. Un audit rapide de Github Actions montre que 60 à 70% des dépôts publics qui utilisent ce déclencheur ont une configuration vulnérable.

La différence avec pull_request en une phrase

• pull_request : déclenche le workflow dans le contexte du fork, sans accès aux secrets du dépôt cible. C'est le mode sûr par défaut.
• pull_request_target : déclenche le workflow dans le contexte du dépôt cible, avec accès aux secrets, mais en réaction à une PR venue d'un fork.

pull_request_target existe pour des cas légitimes — étiqueter automatiquement les PR, ajouter des commentaires, déclencher des jobs qui ont besoin de secrets. Le problème commence quand un workflow pull_request_target exécute du code venant du fork.

Le pattern dangereux à reconnaître

```yaml on: pull_request_target

jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} - run: npm install - run: npm test ```

Lu vite, ça paraît raisonnable. En réalité :

1. actions/checkout clone le code du fork, contrôlé par l'attaquant.
2. npm install exécute les postinstall du fork — code arbitraire avec les secrets du repo cible.
3. npm test exécute n'importe quel script de test, modifié par l'attaquant.

Tout cela tourne avec GITHUB_TOKEN et les secrets.* du dépôt cible. L'attaquant n'a qu'à ouvrir une PR depuis un fork pour exécuter du code arbitraire avec vos secrets.

Comment auditer en 5 minutes

``bash find .github/workflows -type f \( -name ".yml" -o -name ".yaml" \) \ -exec grep -l "pull_request_target" {} \; ``

Pour chaque fichier matché, vérifier :

1. Y a-t-il un actions/checkout avec ref: head.sha ou équivalent ?
2. Y a-t-il une exécution de scripts arbitraires (npm install, pip install, make, bash) ?
3. Le workflow accède-t-il à secrets.* ?

Si oui aux trois, vous êtes vulnérable.

Les corrections par ordre de force

Correction faible : check du committer

Vérifier que l'auteur de la PR est un mainteneur connu :

``yaml if: github.event.pull_request.head.repo.full_name == github.repository ``

Ça empêche les forks de déclencher. Suffisant si vous n'avez besoin de pull_request_target que pour des PR internes.

Correction moyenne : séparer les responsabilités

Deux workflows :

• Un en pull_request (sans secrets) qui fait les tests sur le code du fork.
• Un en pull_request_target (avec secrets) qui se contente d'étiqueter, commenter, déclencher un déploiement de preview — sans exécuter de code du fork.

C'est la posture recommandée par GitHub dans la doc actuelle. C'est aussi ce que beaucoup de projets ont oublié de faire en gardant un workflow historique.

Correction forte : pas de checkout du fork dans pull_request_target

Si vous devez absolument lire le code de la PR depuis un workflow pull_request_target, ne l'exécutez pas. Lisez-le, parsez-le, analysez-le. Ne lancez ni install ni test ni build.

Au-delà de la correction : les patterns à éviter durablement

Pas d'auto-merge sur pull_request_target

Si un workflow pull_request_target mergeait automatiquement après tests, vous donnez à un attaquant la possibilité d'auto-mergeer son propre code. C'était la racine de plusieurs CVE GitHub Actions en 2024-2025.

Pas de cache restore en pull_request_target

Cf. Cache poisoning des GitHub Actions. Un fork peut potentiellement empoisonner le cache pour des exécutions ultérieures.

Audit annuel des workflows

Un workflow ajouté en 2022 pour un besoin temporaire peut être devenu un trou. Le ré-auditer une fois par an, en croisant avec les CVE GitHub Actions de l'année, prend une demi-journée.

L'état du parc en mai 2026

Un scan publié par Wiz le 16 mai 2026 indique que sur un échantillon de 50 000 dépôts publics utilisant pull_request_target :

• 64% chargent du code du fork avec actions/checkout + head.sha.
• 41% exécutent ensuite un install ou un test.
• 38% accèdent à des secrets dans le même job.

Donc environ 30% des dépôts qui utilisent pull_request_target sont vulnérables au schéma exact exploité par Shai-Hulud. C'est massif. Et c'est ce qui rend ce vecteur si attractif pour les attaquants en 2026.

Pour la lecture du cache poisoning lié, Cache poisoning des GitHub Actions. Pour l'audit complet des actions tierces utilisées, Supply chain : auditer vos GitHub Actions.