À partir du 2 décembre 2026, GitHub Actions bloquera par défaut l'événement pull_request_target dans tous les dépôts publics, sauf lorsqu'une politique d'événements Actions l'autorise explicitement. L'information est CONFIRMÉE : elle figure dans le journal des modifications officiel de GitHub, publié le 2 novembre 2026.
L'application était d'abord prévue le 2 novembre et a été reportée au 2 décembre. D'ici là, la règle par défaut fonctionne en mode évaluation : les workflows continuent de s'exécuter, mais GitHub indique quelles exécutions seraient bloquées, afin que les mainteneurs ajustent leurs politiques avant le blocage définitif.
Avant l'application permanente, GitHub imposera temporairement la règle lors de deux fenêtres de test, les « brownouts », les 9 et 16 novembre 2026, de 16h00 à 18h00 UTC. Pendant ces fenêtres, les tentatives bloquées deviennent des exécutions en échec avec une annotation d'erreur, sans exécuter le workflow ; après chaque fenêtre, la règle revient en mode évaluation, avec des avertissements.
Le risque qui motive ce changement est connu : pull_request_target s'exécute dans le contexte du dépôt de base et peut accéder à ses secrets. Si un workflow exécute du code non fiable provenant d'un fork, ce code pourrait compromettre le pipeline ou voler des secrets — la classe d'attaque connue sous le nom de Pwn Request. GitHub recommande donc de consulter, avant le premier brownout du 9 novembre, le rapport Insights, qui montre quelles exécutions seraient bloquées.
Ce que les mainteneurs doivent faire
Il existe deux options, selon GitHub : conserver la règle par défaut, en laissant le déclencheur bloqué, ou autoriser explicitement pull_request_target dans une politique d'événements applicable, en ciblant de préférence uniquement les fichiers de workflow qui en dépendent réellement. Il ne s'agit pas d'une interdiction absolue : les dépôts dotés d'une politique explicite pourront continuer à utiliser le déclencheur.
La règle n'affecte pas les dépôts privés et internes, et elle s'applique aux dépôts publics sur GitHub Free, GitHub Team et GitHub Enterprise Cloud — pas à GitHub Enterprise Server. L'application automatique du 2 décembre vaut pour les dépôts concernés qui utilisaient la politique par défaut de pull_request_target avant la disponibilité générale des protections d'exécution des workflows.
En pratique, le message adressé aux mainteneurs d'automatisations de pull requests de forks — comme les étiqueteurs, le triage et les vérifications authentifiées — est simple : auditez maintenant, en mode évaluation, et n'autorisez que le nécessaire. Attendre le 2 décembre, c'est risquer des échecs silencieux dans des automatisations qui semblent fonctionner aujourd'hui.
Crédit image : GitHub, via l'icône officielle de GitHub.
Sources: GitHub Changelog — pull_request_target blocked by default December 2; GitHub Docs — Securely using pull_request_target; GitHub Changelog — Workflow execution protections generally available
Transparence : cet article a été produit avec l'aide de l'intelligence artificielle, à partir du recoupement de publications publiques sur X et de sources sur internet. Consultez les sources originales pour confirmer les détails avant de les partager.
Muse
