GitHub bloquera pull_request_target par défaut dans les dépôts publics dès le 2 décembre, avec des brownouts les 9 et 16 novembre

Le 2 novembre 2026, GitHub a publié une entrée de journal des modifications indiquant que GitHub Actions bloquera par défaut l'événement pull_request_target dans tous les dépôts publics, sauf si une politique d'événements Actions applicable l'autorise explicitement. La date est le détail important. L'entrée précise que l'application était auparavant prévue pour le 2 novembre 2026, et la nouvelle date de l'application permanente est le 2 décembre 2026. L'entrée est classée comme retrait et laisse aux propriétaires de dépôts publics une courte fenêtre pour trouver les workflows qui cesseront de s'exécuter.

La raison est la sécurité. L'événement pull_request_target s'exécute dans le contexte du dépôt de base et peut accéder à ses secrets. Si un workflow qui l'utilise exécute du code non fiable provenant d'un fork, ce code pourrait compromettre le pipeline ou voler des secrets. GitHub dit que la règle par défaut réduit ce risque tout en laissant les propriétaires autoriser volontairement les workflows qui dépendent de ce déclencheur. La règle a été introduite par les protections d'exécution des workflows et fonctionne d'abord en mode évaluation, de sorte que les propriétaires peuvent voir quelles exécutions elle bloquerait avant le début de l'application.

La portée compte, et l'entrée la formule de façon étroite. Le changement s'applique aux dépôts publics sur GitHub Free, GitHub Team et GitHub Enterprise Cloud. Il ne s'applique pas à GitHub Enterprise Server. Les dépôts privés et internes ne sont pas concernés. Une organisation qui mélange plusieurs types de dépôts doit donc d'abord lister ses dépôts publics, car eux seuls risquent une exécution bloquée.

Avant l'application permanente, GitHub appliquera la protection par défaut pendant deux brownouts planifiés. Ils ont lieu le 9 novembre 2026 et le 16 novembre 2026, chacun de 16 h 00 à 18 h 00 UTC. Pendant ces fenêtres, les tentatives d'exécution de workflows pull_request_target que la règle par défaut bloque dans les dépôts publics concernés créent des exécutions en échec avec une annotation d'erreur, et les workflows ne s'exécutent pas. Après chaque fenêtre, la règle revient en mode évaluation et les workflows s'exécutent à nouveau avec des avertissements. Un brownout est donc une vraie interruption pour ces workflows, pas une répétition sur le papier.

L'entrée propose deux choix. Avant le premier brownout, utilisez Insights pour voir quelles exécutions la règle bloquerait. Ensuite, soit vous conservez la règle par défaut pour que le déclencheur reste bloqué, soit vous autorisez explicitement pull_request_target dans une politique d'événements Actions applicable si vos workflows en dépendent, en ciblant des fichiers de workflow pour n'autoriser que certains workflows. Autoriser l'événement pour tout un dépôt est une décision plus large que d'en autoriser un seul fichier, et l'entrée renvoie à la documentation sur le contrôle de l'exécution des workflows.

Cette documentation ajoute des détails que l'entrée ne répète pas. Les protections d'exécution des workflows peuvent restreindre qui peut déclencher les workflows, restreindre les événements autorisés et exiger un fichier de verrouillage. Les règles d'événements couvrent des événements comme push, pull_request, pull_request_target et workflow_dispatch. Avec les règles d'acteurs, une identité liée à une fonction de GitHub, par exemple dependabot[bot], doit être ajoutée comme acteur autorisé lorsqu'elle doit exécuter des workflows. La documentation dit que les politiques peuvent être définies aux niveaux dépôt, organisation et entreprise et recommande plusieurs politiques bien définies plutôt qu'une seule grande. Elle révèle aussi un point à vérifier. La page indique que si vous choisissez le statut d'application Évaluer (Evaluate) pour une politique, vous pouvez surveiller dans les informations de politique quand des utilisateurs atteindraient une restriction, et elle précise que l'évaluation est réservée à GitHub Enterprise Cloud. Le journal des modifications dit que la règle par défaut démarre en mode évaluation pour les dépôts publics sur Free, Team et Enterprise Cloud. Ces pages n'expliquent pas si les propriétaires Free et Team obtiennent la même vue Insights ; vérifiez-le dans vos propres paramètres avant de vous y fier.

Un plan pratique est court. Trouvez tous les workflows des dépôts publics qui utilisent pull_request_target. Pour chacun, décidez s'il a vraiment besoin des secrets du dépôt de base ou d'autorisations d'écriture, ou si pull_request suffit. S'il doit rester, examinez quel code il récupère depuis le fork, car c'est le schéma dangereux visé par la règle. Ajoutez ensuite une autorisation explicite pour ce seul fichier, notez le responsable et la raison, et testez pendant la fenêtre du 9 novembre. Considérez le 2 décembre comme la date à partir de laquelle l'absence de règle d'autorisation signifie un workflow qui ne s'exécute tout simplement pas.