GitHub bloquera pull_request_target par défaut dans les dépôts publics

Le 2 décembre 2026, GitHub prévoit de bloquer par défaut les événements pull_request_target dans les dépôts publics, sauf autorisation explicite par une politique Actions applicable. Deux périodes de mise en application temporaire précèdent cette date. Cette règle protège une frontière sensible et peut interrompre des workflows attendus.

Dates et périmètre

GitHub a publié le calendrier actualisé le 2 novembre. Avant l’application permanente, la règle est en mode évaluation : hors des fenêtres temporaires, les workflows concernés peuvent s’exécuter avec des avertissements.

Pendant ces fenêtres, une exécution bloquée échoue avec une annotation d’erreur et le workflow ne s’exécute pas. La règle concerne les dépôts publics sur GitHub Free, Team et Enterprise Cloud. GitHub précise qu’elle ne concerne ni les dépôts privés ou internes ni GitHub Enterprise Server.

Pourquoi cet événement mérite une revue

pull_request_target s’exécute dans le contexte du dépôt de base. Selon la référence de sécurité GitHub, des workflows privilégiés peuvent accéder aux permissions d’écriture, aux secrets référencés et au cache de la branche principale. Extraire puis exécuter le contenu non fiable d’une pull request dans ce contexte peut compromettre le pipeline ou exposer des secrets.

Le nom du déclencheur ne suffit pas à démontrer une faille. Examinez le code, les scripts et les artefacts réellement traités, les permissions et secrets accessibles, et l’influence possible d’un fork sur ces entrées. GitHub recommande aussi de traiter avec prudence les artefacts issus d’exécutions non fiables dans un workflow workflow_run.

Avant la première fenêtre

1. Utilisez Insights pour repérer les exécutions que la règle bloquerait et identifiez le responsable de chaque workflow.
2. Déterminez si le job a besoin du déclencheur privilégié. Pour exécuter du code non fiable, envisagez pull_request avec les permissions minimales. Testez les forks et les réglages du dépôt ; changer le déclencheur ne remplace pas une revue de sécurité.
3. Si le workflow privilégié est nécessaire, évitez d’exécuter du code non fiable, limitez les permissions et examinez la frontière des artefacts. GitHub explique comment contrôler l’exécution des workflows.
4. Conservez le blocage par défaut lorsque c’est possible. Si l’événement est nécessaire, GitHub propose des politiques explicites ciblant les workflows. Validez chaque exception : autoriser l’exécution ne rend pas son entrée fiable.
5. Effectuez un test contrôlé avant le 9 novembre et définissez un responsable ainsi qu’un plan de retour arrière.

Relier la décision aux preuves

La politique détermine si un workflow peut démarrer. La revue doit aussi conserver des preuves du code exécuté et des identifiants accessibles : version du workflow, origine de l’événement et résultat observé.

AI Swarm Pentest de Plexicus décrit une validation fondée sur des preuves des applications et API autorisées ; remediation aide à transformer les résultats validés en correctifs examinables. Utilisez ces workflows avec une revue séparée de GitHub Actions : un scan applicatif ne prouve pas à lui seul que la politique du workflow est sûre.

Examinez les dépôts concernés avant la première fenêtre. Découvrir Plexicus remediation.

Image : capture d’un paragraphe original de GitHub Docs, Secure use reference, sous CC BY 4.0. Elle n’implique aucun soutien.