GitHub bloquera pull_request_target le 2 novembre

GitHub appliquera le 2 novembre 2026 une règle bloquant par défaut les workflows déclenchés par pull_request_target dans certains dépôts publics. Les protections d’exécution de GitHub Actions sont généralement disponibles depuis le 17 septembre et, selon le changelog de GitHub, la règle reste jusque-là en mode Evaluate : les exécutions continuent, mais Policy insights signale celles qui seraient refusées.

Le blocage du 2 novembre 2026 ne concernera pas tous les dépôts GitHub Actions. Il vise les dépôts publics auxquels GitHub avait attribué cette règle par défaut avant la disponibilité générale parce qu’aucune politique d’événements applicable n’existait déjà; les dépôts privés et internes sont exclus de cette application automatique. L’analyse publiée par Nandann le 18 septembre confirme ce calendrier et ce périmètre.

Pourquoi ce déclencheur peut donner accès aux secrets

pull_request_target s’exécute avec le niveau de confiance du dépôt de base. Le job peut donc recevoir son GITHUB_TOKEN et accéder aux secrets du dépôt ou de l’organisation, ce qui permet notamment d’étiqueter une pull request issue d’un fork, d’effectuer du triage ou de publier un contrôle authentifié.

Le déclencheur n’exécute cependant pas, à lui seul, le code proposé par le fork. Le fichier de workflow et un appel à actions/checkout sans référence explicite proviennent par défaut de la branche principale du dépôt de base. Le danger apparaît lorsque le workflow récupère volontairement la tête ou le commit de fusion d’une pull request non fiable, puis construit, teste ou exécute ce contenu dans le contexte privilégié.

Le guide de sécurité de GitHub décrit ce schéma de « pwn request » : un Makefile, un script d’installation, une dépendance ou une configuration contrôlée par l’auteur du fork peut exécuter des commandes ayant accès au jeton et aux secrets. Il recense aussi les récupérations indirectes par git fetch, gh pr checkout ou téléchargement d’un artefact comme des chemins à examiner.

Les dépôts placés dans le périmètre automatique

Trois conditions délimitent le changement. Le dépôt doit être public, ne pas avoir de politique d’événements Actions déjà applicable et avoir utilisé la politique pull_request_target par défaut avant le passage en disponibilité générale. Une règle configurée au niveau du dépôt, de l’organisation ou de l’entreprise n’est pas remplacée par ce réglage automatique.

Un dépôt privé ou interne ne sera donc pas soumis à ce blocage par défaut, même s’il peut employer les mêmes protections d’exécution. De même, la présence de pull_request_target dans un dépôt public ne suffit pas à prédire une interruption : il faut identifier la politique effectivement applicable et vérifier si le dépôt a reçu la règle par défaut concernée.

Le ciblage par fichier, ajouté avec la disponibilité générale, permet d’éviter une décision uniforme pour tout le dépôt. Une automatisation de triage qui dépend légitimement de pull_request_target peut être explicitement autorisée pour un fichier déterminé, tandis qu’un workflow de test exécutant le code des contributeurs peut être déplacé vers pull_request.

Evaluate signale les refus sans interrompre les jobs

Le mode Evaluate sert à observer l’effet d’une politique avant son application. Une exécution qui ne respecte pas la règle apparaît dans Policy insights comme une exécution qui aurait été bloquée, mais elle démarre encore. Après activation, la même incompatibilité empêche le workflow de commencer.

Les protections distinguent les acteurs autorisés des événements autorisés. Elles peuvent être définies aux niveaux entreprise, organisation et dépôt, puis limitées à des chemins de workflows précis. Comme plusieurs politiques peuvent se superposer, consulter uniquement les paramètres locaux d’un dépôt ne suffit pas toujours à expliquer pourquoi une exécution serait refusée.

Evaluate ne constitue pas une preuve qu’un workflow est sûr. Il mesure l’effet de la règle d’exécution; il ne contrôle pas les commandes lancées après le démarrage, la portée réelle du GITHUB_TOKEN, les secrets transmis au job ni l’accès réseau d’un runner auto-hébergé.

La check-list d’audit avant le 2 novembre

L’objectif est de relier chaque occurrence de pull_request_target à la politique qui la couvre et au contenu qu’elle exécute. Le parcours suivant est une recommandation d’audit, pas le résultat d’un test interne.

Recenser les fichiers sous .github/workflows qui déclarent pull_request_target, y compris les automatisations rarement exécutées.
Consulter Policy insights aux niveaux pertinents et relever les fichiers dont les exécutions seraient bloquées par la règle en mode Evaluate.
Vérifier si chaque workflow récupère le code d’un fork par actions/checkout, git fetch, gh pr checkout ou au moyen d’un artefact, puis déterminer si une étape exécute ce contenu.
Examiner les permissions effectives du GITHUB_TOKEN, les secrets du dépôt ou de l’organisation, les environnements protégés et l’accès éventuel à un runner auto-hébergé.
Remplacer pull_request_target par pull_request lorsque le job doit tester du code non fiable sans avoir besoin de secrets ni d’un jeton privilégié.
Si le déclencheur reste indispensable, créer ou modifier une politique d’événements qui l’autorise explicitement et limiter l’exception au fichier concerné lorsque c’est possible.
Contrôler de nouveau Policy insights afin de repérer les exécutions légitimes encore signalées avant de passer la politique en application.

Autoriser explicitement un fichier ne corrige pas un workflow qui exécute du code non fiable avec des privilèges élevés. L’exception doit rester accompagnée de permissions minimales, d’un périmètre de secrets réduit et d’une séparation nette entre l’analyse du contenu proposé et toute opération authentifiée.

Ce qui changera au moment de l’application

Le 2 novembre 2026, si le calendrier annoncé est maintenu, la politique par défaut passera de l’évaluation au blocage pour les dépôts entrant dans le périmètre. Leurs workflows pull_request_target ne démarreront plus, sauf si une politique applicable autorise cet événement.

À ce stade, la disponibilité générale est acquise, mais le blocage automatique reste une échéance future. La principale inconnue pour chaque équipe n’est donc pas la date : c’est la liste exacte des dépôts et fichiers encore dépendants du déclencheur, que le mode Evaluate doit permettre d’établir avant l’application.

GitHub Actions bloquera pull_request_target par défaut le 2 novembre