GitHub Actions : pull_request_target bloqué par défaut le 2 décembre, premières coupures test ce 9 novembre
À partir du 2 décembre 2026, GitHub bloquera par défaut le déclencheur pull_request_target dans tous les dépôts publics. Avant cela, deux coupures test de deux heures, les 9 et 16 novembre de 17 h à 19 h (heure de Paris), feront échouer les workflows concernés.
Si vous maintenez un dépôt public sur GitHub qui utilise le déclencheur pull_request_target, notez l’horaire : ce lundi 9 novembre, de 17 h à 19 h (heure de Paris), vos workflows risquent d’échouer. C’est la première des deux coupures test annoncées par GitHub avant le blocage par défaut de ce déclencheur, le 2 décembre 2026, dans tous les dépôts publics (changelog).
Pourquoi ce déclencheur est visé
pull_request_target sert surtout à automatiser des réactions aux pull requests venues de forks : étiquetage, tri, commentaires, statuts. Sa particularité : il s’exécute dans le contexte du dépôt de base, avec accès à ses secrets et à un jeton en écriture. Tant que le workflow ne lance que du code de la branche par défaut, c’est sans danger. Mais s’il récupère et exécute le code de la pull request, un contributeur malveillant peut compromettre la chaîne d’intégration ou voler des secrets. C’est la raison avancée par GitHub, dont la documentation prévient : un workflow déclenché ainsi ne doit jamais construire ni exécuter le code d’une pull request non fiable avec accès aux secrets.
Le calendrier
- Jusqu’au 2 décembre : la règle par défaut tourne en mode évaluation, les workflows s’exécutent avec des avertissements.
- 9 et 16 novembre, 16 h-18 h UTC (17 h-19 h à Paris) : blocage temporaire. Les workflows concernés créent des exécutions en échec avec une annotation d’erreur.
- 2 décembre : blocage permanent par défaut, sauf autorisation explicite. L’échéance initiale était le 2 novembre.
Sont concernés les dépôts publics sur GitHub Free, Team et Enterprise Cloud. Les dépôts privés et internes et GitHub Enterprise Server ne le sont pas.
Que faire avant lundi
GitHub conseille d’ouvrir les Insights pour repérer les exécutions qui seraient bloquées. Ensuite, trois cas : si le workflow n’a pas besoin de secrets ni d’écriture, passer au déclencheur pull_request ; s’il en a vraiment besoin, l’autoriser dans une politique d’événements Actions en ciblant uniquement ce fichier de workflow, et vérifier qu’il n’exécute jamais le code de la pull request ; sinon, laisser le blocage faire son travail.
Notre lecture
pull_request_target est un piège bien connu des mainteneurs, car la frontière entre « réagir à une pull request » et « exécuter son code » est facile à franchir par mégarde. Inverser le réglage par défaut est la bonne décision, et les coupures test évitent la surprise du jour J. L’enjeu grandit avec les agents de code qui ouvrent des pull requests à grande échelle sur des projets publics : plus il y a de contributions automatisées, plus un workflow trop permissif devient une cible. Pour les mainteneurs, le travail est court mais à faire maintenant : quelques minutes dans les Insights évitent une soirée de CI en rouge.
Sources
- GitHub Changelog — pull_request_target blocked by default December 2 (2 novembre 2026) Source primaire
- GitHub Docs — Securely using pull_request_target Source primaire
Une source primaire émane directement de l'entreprise, du laboratoire ou de l'organisme concerné. Une source secondaire rapporte l'information sans en être l'auteur : nous la signalons comme telle. Une erreur ? Consultez notre politique de correction.
