GitHub Actions : pull_request_target bloqué le 2 décembre

Le déclencheur le plus risqué de la CI de GitHub va être désactivé par défaut. À partir du 2 décembre 2026, GitHub Actions bloquera les événements pull_request_target dans tous les dépôts publics, sauf si une politique d'événements les autorise explicitement. Annoncée le 2 novembre dans le changelog de GitHub, l'échéance était initialement fixée à cette même date du 2 novembre et a donc été repoussée d'un mois.

Pourquoi ce déclencheur pose problème

Contrairement à pull_request, le déclencheur pull_request_target s'exécute dans le contexte du dépôt de base, et non dans celui de la branche proposée. Le workflow a donc accès aux secrets du dépôt et à un jeton aux droits plus étendus. Ce comportement est utile pour, par exemple, étiqueter automatiquement une pull request venue d'un fork ou y publier un commentaire.

Le danger apparaît lorsque le workflow récupère et exécute le code de la pull request elle-même. GitHub le résume ainsi : si un workflow exécute du code non fiable provenant d'un fork, ce code peut compromettre le pipeline ou dérober des secrets. Ce scénario, souvent qualifié de « pwn request », est à l'origine de plusieurs compromissions de chaînes d'approvisionnement logicielles ces dernières années.

Une règle par défaut, déjà en observation

Le blocage passe par une règle par défaut des protections d'exécution des workflows. Elle fonctionne pour l'instant en mode évaluation : les workflows continuent de tourner, mais GitHub indique lesquels seraient bloqués.

Avant l'application définitive, deux coupures programmées (« brownouts ») sont prévues pour repérer les workflows concernés :

• 9 novembre 2026, de 16 h à 18 h UTC ;
• 16 novembre 2026, de 16 h à 18 h UTC.

Pendant ces fenêtres, les exécutions pull_request_target bloquées produiront des runs en échec, accompagnés d'une annotation d'erreur, et les workflows ne s'exécuteront pas. Entre les deux, la règle reviendra en mode évaluation avec de simples avertissements.

Qui est concerné

Le changement touche les dépôts publics sur GitHub Free, GitHub Team et GitHub Enterprise Cloud. Les dépôts privés et internes ne sont pas concernés, pas plus que GitHub Enterprise Server.

Comment se préparer

GitHub recommande de consulter, avant le 9 novembre, la vue Insights des protections d'exécution pour identifier les runs qui seraient bloqués. Deux options s'offrent ensuite aux mainteneurs :

1. Conserver la règle par défaut et laisser pull_request_target bloqué, ce qui suffit si le déclencheur n'est pas utilisé ou peut être remplacé par pull_request ;
2. Autoriser explicitement le déclencheur dans une politique d'événements Actions, en ciblant si possible uniquement les fichiers de workflow qui en ont besoin.

Dans le second cas, l'autorisation ne règle pas le problème de fond : un workflow pull_request_target ne doit jamais extraire ni exécuter le code de la branche proposée avec les secrets du dépôt. Limiter les permissions du jeton et séparer les tâches qui manipulent du code non fiable restent de mise.

Cette mesure s'inscrit dans un durcissement plus large de la CI de GitHub, après l'arrivée en test des lockfiles de workflow, qui figent chaque action utilisée sur un commit précis.