GitHub Actions : checkout v7 bloque enfin les pwn requests

Publié le 22 juin 2026

8 min de lecture

#github-actions#securite#devsecops#supply-chain#ci-cd

Depuis des semaines, je répète la même mise en garde dans mes audits et mes guides : un workflow en pull_request_target qui checkoute le code d'un fork, c'est la porte ouverte au vol de vos secrets. Cette attaque porte un nom, la pwn request, et elle a fait des dégâts bien réels. La bonne nouvelle de ce mois de juin 2026 : GitHub pose enfin un garde-fou par défaut dans actions/checkout@v7. Voici ce que ça change concrètement, l'exception à ne pas laisser traîner, et pourquoi presque tous les dépôts seront concernés à la mi-juillet.

La pwn request, en deux phrases

pull_request_target exécute la définition du workflow du dépôt cible (le vôtre), avec accès aux secrets, y compris pour une PR venue d'un fork. Le piège : si une étape checkoute ensuite le code de la PR (ref: github.event.pull_request.head.sha) puis l'exécute (un npm install, un script de build), c'est le code de l'attaquant qui tourne avec vos credentials. Pour le détail et les patterns sûrs, j'ai un guide dédié : Sécuriser pull_request_target.

Ce que change checkout v7

Jusqu'ici, rien n'empêchait techniquement ce checkout dangereux : la responsabilité reposait entièrement sur le mainteneur. Avec actions/checkout@v7, le comportement par défaut s'inverse : quand un workflow pull_request_target (ou certains workflow_run) tente de récupérer la ref d'un fork (la branche ou le SHA de la PR), checkout refuse l'opération. Le pattern dangereux échoue au lieu de tirer silencieusement du code non fiable dans un runner privilégié.

C'est un vrai changement de philosophie : le garde-fou passe du « bonne chance, fais attention » à un refus par défaut. La bonne valeur par défaut, enfin.

allow-unsafe-pr-checkout : l'exception à surveiller

Certains workflows légitimes ont besoin du code de la PR (un linter qui commente la PR, par exemple). Pour ces cas, checkout v7 ajoute un input allow-unsafe-pr-checkout qui réautorise explicitement l'ancien comportement.

Mon conseil : grepez vos dépôts pour allow-unsafe-pr-checkout et exigez une justification écrite pour chaque occurrence.

Le backport du 16 juillet : pourquoi presque tous les dépôts sont concernés

Le point que beaucoup vont rater : ce n'est pas réservé à ceux qui passeront en v7. D'après l'analyse de Socket, la protection est rétroportée le 16 juillet 2026 sur toutes les versions majeures supportées. Comme l'écrasante majorité des workflows épinglent checkout sur un tag flottant (actions/checkout@v4, @v3), ils hériteront automatiquement du nouveau comportement à cette date.

Conséquence concrète : si un de vos pipelines repose aujourd'hui sur un checkout de fork en pull_request_target (en connaissance de cause ou non), il risque de casser le 16 juillet. Mieux vaut l'auditer maintenant que le découvrir en production.

Ce backport illustre un arbitrage d'épinglage : un tag flottant (@v4) reçoit ce changement gratuitement (ici, une bonne surprise), mais vous expose aussi aux évolutions non désirées ; l'épinglage par SHA vous rend maître du calendrier, au prix de devoir adopter checkout v7 vous-même pour obtenir cette protection. Les deux se défendent, à condition de choisir en connaissance de cause.

Ce que checkout v7 ne règle pas

Un garde-fou n'est pas une dispense de rigueur. Ce changement réduit une classe d'attaque, il ne sécurise pas vos workflows à votre place :

L'injection de templates (${{ github.event.issue.title }} dans un run:) reste entièrement possible.
Les permissions trop larges du GITHUB_TOKEN restent un problème si vous ne les réduisez pas explicitement.
Le pattern à deux workflows (un pull_request non privilégié qui builde, un workflow_run privilégié qui publie) reste la bonne architecture pour traiter les PR de forks proprement.

Tout cela est couvert dans le guide Attaques supply chain sur GitHub Actions.

Mon conseil : évitez-le quand vous pouvez

Soyons clairs sur mon avis : par défaut, je déconseille pull_request_target. Le garde-fou de checkout v7 est une bonne nouvelle, mais ce déclencheur reste le plus dangereux de GitHub Actions, et la plupart des besoins se couvrent autrement :

pour tester ou builder une PR de fork : pull_request (sans secrets) suffit ;
pour une étape privilégiée (déployer une preview, publier un commentaire) : le pattern à deux workflows relié par workflow_run, ou une action API-only sans checkout du code du fork.

Je le réserve aux rares cas qui n'exécutent jamais le code du fork (labeling, commentaire via l'API), et encore, en pesant vraiment le besoin. Un déclencheur qu'on n'utilise pas est un déclencheur qu'on n'a pas à sécuriser.

Ce que je ferais rapidement

Repérer les workflows à risque : grep -r "pull_request_target" .github/workflows/, puis vérifier ceux qui checkoutent github.event.pull_request.head et exécutent ce code.
Corriger la cause, sans attendre v7 : supprimer le checkout du fork, ou passer au pattern à deux workflows. C'est la seule vraie protection, indépendante de la version de checkout.
Anticiper le 16 juillet selon votre épinglage :
- tag flottant (@v4) : la protection arrive toute seule, mais un pipeline qui dépendait du comportement dangereux cassera ce jour-là. Testez avant.
- épinglé par SHA : vous ne l'aurez pas automatiquement, il faudra passer explicitement à checkout v7.
Réserver allow-unsafe-pr-checkout à l'exception : ne l'activez que sur un cas justifié, et traquez son apparition en revue de PR.
Mettre la détection en continu : plumber (ISSUE-804), zizmor et poutine repèrent ces checkouts dangereux, pour ne pas régresser.

À retenir

Mon réflexe par défaut : évitez pull_request_target. Le garde-fou v7 réduit le risque, il ne rend pas le déclencheur désirable pour autant.
actions/checkout@v7 refuse par défaut de checkouter la ref d'un fork sous pull_request_target : la pwn request est bloquée nativement.
L'input allow-unsafe-pr-checkout rouvre la porte : à traiter comme une exception sensible, jamais par confort.
Rétroportage le 16 juillet 2026 sur les majeures supportées : les tags flottants (@v4, @v3) hériteront de la protection, et certains pipelines casseront s'ils dépendaient du comportement dangereux.
Le garde-fou ne remplace ni les permissions minimales, ni la lutte contre l'injection, ni le pattern à deux workflows.
C'est une bonne valeur par défaut de plus : auditez maintenant, ne subissez pas.

Pour aller plus loin

Dernier réflexe supply chain : au-delà de vos propres workflows, évaluez vos fournisseurs. Le radar de plumber note la posture sécurité des libs et applications dont vous dépendez.

Et d'ailleurs, c'est quoi votre plumber score ?