GitHub Actions bloquera par défaut un déclencheur privilégié de pull request le 2 décembre
GitHub a reporté l’entrée en vigueur d’une mesure de sécurité de GitHub Actions, selon son annonce du 2 novembre. À partir du 2 décembre 2026, les événements pull_request_target seront bloqués par défaut dans les dépôts publics, sauf si une règle Actions applicable les autorise explicitement. La date initialement prévue était le 2 novembre. GitHub indique que la règle fonctionne actuellement en mode d’évaluation, pour permettre aux responsables de repérer les exécutions concernées avant son application.
Tous les workflows GitHub Actions ne vont donc pas s’arrêter. La mesure vise l’événement pull_request_target dans les dépôts publics sur GitHub Free, Team et Enterprise Cloud. Elle ne concerne ni les dépôts privés ou internes, ni GitHub Enterprise Server. L’annonce GitHub du 2 novembre (en anglais) en précise le périmètre.
Pourquoi GitHub durcit le comportement par défaut
L’événement pull_request_target s’exécute dans le contexte de sécurité du dépôt qui reçoit la pull request, plutôt que dans celui du fork contenant le code non fiable. Ce fonctionnement peut servir à des tâches de maintenance bien encadrées. Il devient dangereux si un workflow récupère puis exécute une contribution non fiable tout en ayant accès à des secrets ou à un jeton autorisant l’écriture.
La nouvelle règle ne remplace pas la conception d’un workflow sûr. Le responsable d’un dépôt qui autorise volontairement pull_request_target doit toujours examiner les permissions du job et vérifier s’il exécute des éléments contrôlés par un contributeur non fiable.
Deux blocages temporaires avant le 2 décembre
GitHub prévoit deux fenêtres d’application temporaire, exprimées en UTC :
| Date | Fenêtre de blocage (UTC) | Comportement attendu |
|---|---|---|
| 9 novembre 2026 | De 16 h à 18 h | Les exécutions concernées seront bloquées et marquées en échec avec une annotation d’erreur |
| 16 novembre 2026 | De 16 h à 18 h | La même règle sera temporairement appliquée |
| 2 décembre 2026 | Début de l’application permanente | Les exécutions concernées dans les dépôts publics seront bloquées par défaut, sauf autorisation explicite |
En dehors de ces fenêtres, avant le 2 décembre, GitHub indique que la règle repassera en mode d’évaluation : les workflows pourront s’exécuter avec des avertissements. Un échec pendant un blocage temporaire ne signifie donc pas nécessairement que les tests, les scripts de compilation ou le code de l’application sont défectueux. Commencez par lire l’annotation GitHub Actions.
Examiner les workflows concernés avant le 9 novembre
Recherchez pull_request_target dans le répertoire .github/workflows/ de vos dépôts publics. Pour chaque occurrence, vérifiez si ce déclencheur est nécessaire, si le job dispose de secrets ou de droits d’écriture, et s’il exécute du contenu non fiable issu d’une pull request. Changer simplement de déclencheur sans examiner le modèle de permissions peut créer un autre problème.
GitHub recommande de consulter Insights pour identifier les exécutions qui seraient bloquées. Les équipes peuvent conserver la règle par défaut ou définir une autorisation explicite dans une règle d’événement Actions. Le ciblage par fichier de workflow permet de limiter les exceptions. Consultez la documentation officielle sur le contrôle des workflows (traduction française partielle) et vérifiez le comportement des règles dans les paramètres de votre dépôt.
Si votre dépôt déploie une application web ou une API, séparez aussi la validation des pull requests non fiables de la publication avec des privilèges. Une compilation réussie ne doit pas donner automatiquement accès aux identifiants de production. Le guide des diagrammes de séquence d’API avec Mermaid peut vous aider à représenter les événements qui déclenchent tests, revues, déploiements et appels d’API. Utilisez l’éditeur Mermaid gratuit pour dessiner votre propre flux.