Pourquoi GitHub désactive-t-il pull_request_target par défaut ?

GitHub justifie cette mesure par un risque de sécurité majeur : les événements pull_request_target s’exécutent dans le contexte du dépôt de base et peuvent accéder à ses secrets, comme les clés API ou les tokens d’authentification. Selon GitHub, si un workflow exécute du code non fiable provenant d’une branche issue d’un fork, celui-ci pourrait compromettre l’intégrité de la pipeline ou voler des informations sensibles. Cette vulnérabilité est exploitée lorsque des contributeurs externes soumettent des modifications via des pull requests depuis des dépôts qu’ils ne contrôlent pas.

Si un workflow exécute du code non fiable provenant d’une branche issue d’un fork, celui-ci pourrait compromettre votre pipeline ou voler des secrets.

Quels dépôts et workflows sont concernés ?

Cette restriction s’applique uniquement aux dépôts publics sur les plateformes GitHub Free, GitHub Team et GitHub Enterprise Cloud, à l’exclusion des dépôts privés et internes. Elle ne concerne pas non plus les instances auto-hébergées comme GitHub Enterprise Server. Les workflows dépendant de pull_request_target devront être explicitement autorisés via une Actions event policy personnalisée, une option déjà disponible pour les utilisateurs avancés.

Comment les organisations peuvent-elles se préparer ?

GitHub propose un outil d’Insights permettant d’identifier à l’avance les workflows qui seraient bloqués par cette règle. Deux phases de tests, appelées brownouts, sont prévues les 9 et 16 novembre 2026 (de 16h à 18h UTC) pour simuler l’enforcement. Pendant ces périodes, les workflows concernés échoueront avec une annotation d’erreur, mais ne s’exécuteront pas. Les équipes disposent donc de deux semaines pour ajuster leurs configurations avant la mise en place définitive le 2 décembre 2026.

Ce que cela change ici pour les entreprises et administrations d’Afrique de l’Ouest

Pour les entreprises béninoises ou ouest-africaines utilisant GitHub Actions dans des projets ouverts (comme des contributions à des logiciels libres ou des dépôts publics pour des partenariats), cette mesure pourrait imposer une refonte des workflows automatisés liés aux pull requests. Les organisations devront évaluer si leurs pipelines dépendent de fonctionnalités spécifiques de pull_request_target, comme l’exécution de tests ou de validations sur des dépôts externes, et les remplacer par des alternatives sécurisées. Les administrations publiques, si elles publient du code source ouvert, devront aussi s’assurer que leurs processus de validation ne reposent pas sur des mécanismes désormais restreints, sous peine de voir leurs automatisations interrompues.