GitHub Actions bloque pull_request_target par défaut dans les dépôts publics le 2 décembre

2 novembre 2026. GitHub annonce que l’événement pull_request_target sera bloqué par défaut dans tous les dépôts publics à compter du 2 décembre 2026. 9 novembre 2026. Premier brownout de 16 h à 18 h UTC, où la règle sera réellement appliquée à titre de test. 16 novembre 2026. Second brownout, même créneau. La mécanique est simple : l’un des déclencheurs les plus dangereux de GitHub Actions cesse d’être disponible par défaut, et quiconque en a encore besoin devra le dire explicitement.

Pour une équipe qui gère de la CI sur des dépôts publics, cette annonce n’est pas une note de bas de page. C’est la fermeture d’un piège vieux de plusieurs années — et une échéance à ne pas rater.

Pourquoi pull_request_target est un piège

La spécificité de pull_request_target tient en une phrase : le workflow s’exécute dans le contexte du dépôt de base, avec accès à ses secrets. À l’inverse de pull_request — qui s’exécute dans le contexte du fork, sans secrets — pull_request_target a été conçu pour les cas où l’automatisation a besoin de privilèges (commenter, étiqueter, déployer une prévisualisation) sur une pull request issue d’un fork.

Le problème est connu depuis longtemps. Si un workflow pull_request_target récupère et exécute du code non fiable venu de la branche de la PR — un checkout du head SHA, puis npm install && npm test, par exemple — alors n’importe quel contributeur d’un fork peut voler les secrets ou compromettre le pipeline. Le motif dangereux ressemble à ceci :

on:
  pull_request_target

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci && npm test

Ici, la ligne ref: …head.sha coche exactement la case du désastre : le runner, lancé avec les privilèges du dépôt de base, exécute du code contrôlé par un tiers. C’est une porte d’entrée classique pour l’exfiltration de GITHUB_TOKEN, de clés npm ou de secrets de déploiement.

Les exemples ne manquent pas : des campagnes de PR de fork qui ciblent des workflows pull_request_target pour exfiltrer des jetons npm, PyPI ou des clés de déploiement sont documentées depuis des années par les équipes de sécurité de l’écosystème open source. Le scénario type est toujours le même : un fork anonyme, une pull request anodine, un workflow trop confiant.

Les trois déclencheurs, et quand les utiliser

Le choix du bon déclencheur n’est pas un détail cosmétique : il détermine quel code s’exécute avec quels privilèges.

La règle de lecture tient en une phrase : plus le contexte est privilégié, plus le code qui s’y exécute doit être de confiance. pull_request est le bon choix pour tout ce qui exécute du code non fiable — là, un contributeur malveillant ne peut pas toucher aux secrets. pull_request_target et workflow_run sont réservés aux actions de confiance qui ne consomment jamais le contenu de la PR comme du code.

C’est précisément cette discipline que la nouvelle règle de GitHub impose par défaut : elle ne supprime pas la possibilité, elle renverse la charge de la preuve — à vous de déclarer que vous avez besoin du contexte privilégié.

Ce que change la règle, et son calendrier

La règle est introduite par le biais des protections d’exécution des workflows (workflow execution protections). Elle fonctionne en deux temps.

Le mode évaluation, maintenant. Jusqu’à la date d’application, la règle tourne en evaluate mode : elle n’empêche rien, mais elle signale les exécutions qu’elle bloquerait. C’est votre fenêtre pour mesurer l’impact sans subir de rupture.

Les brownouts, les 9 et 16 novembre. Pendant ces deux créneaux — de 16 h à 18 h UTC — la protection est réellement appliquée. Les tentatives d’exécution pull_request_target bloquées produiront des runs échoués avec une annotation d’erreur, et le workflow ne s’exécutera pas. Après chaque créneau, la règle revient en mode évaluation. Ces fenêtres sont votre répétition générale gratuite : elles vous montrent précisément quels workflows casseraient le 2 décembre.

L’application définitive, le 2 décembre. À partir de cette date, la règle est permanente. Le périmètre est précis : dépôts publics sur GitHub Free, Team et Enterprise Cloud. Les dépôts privés et internes ne sont pas concernés, tout comme GitHub Enterprise Server.

Le report du 2 novembre au 2 décembre donne un mois de répit de plus — mais le principe ne change pas : la valeur par défaut devient « bloquer ».

Ce qu’il faut faire avant le 2 décembre

Deux options s’offrent à vous, et le bon choix dépend de la raison pour laquelle vous utilisiez pull_request_target.

• Laisser la règle par défaut. Si vos workflows peuvent s’en passer, ne faites rien — c’est la posture la plus sûre. Migrez les cas qui ne nécessitent pas de secrets vers pull_request (build et tests de code non fiable), et réservez les actions privilégiées (étiquetage, commentaires) à un bot ou à un workflow dédié déclenché autrement.
• Autoriser explicitement le déclencheur. Si un workflow légitime dépend réellement de pull_request_target, ouvrez les politiques d’événement Actions et autorisez-le, idéalement en ciblant des fichiers de workflow précis plutôt que d’ouvrir la porte à tout le dépôt.

Pour préparer le terrain, utilisez Insights afin de voir quelles exécutions la règle bloquerait dès maintenant. Les deux brownouts feront ensuite le travail de vérification à votre place : surveillez-les, et chaque run échoué annoté vous dira exactement quoi corriger.

Le fond de la recommandation est plus large : même là où pull_request_target reste autorisé, n’exécutez jamais du code de fork non fiable dans son contexte. Le déclencheur n’est pas l’ennemi ; c’est l’exécution de code tiers avec des secrets qui l’est.

Verdict

Cette règle referme un trou de conception qui a coûté cher à l’écosystème open source — des secrets exfiltrés via de fausses PR de fork, encore et encore. Le calendrier est raisonnable : un mois, deux répétitions générales, et un périmètre clair qui épargne les dépôts privés.

Si votre dépôt public utilise pull_request_target pour tester du code de PR, la bonne réponse n’est pas de le ré-autoriser — c’est de migrer vers pull_request et de déplacer les actions privilégiées hors du chemin du code non fiable. Si vous en dépendez pour des tâches de confiance (étiquettes, commentaires, prévisualisations), autorisez-le explicitement en ciblant les workflows concernés, pas le dépôt entier. Dans les deux cas, ne laissez pas passer les brownouts des 9 et 16 novembre : ce sont les deux seuls tests gratuits que vous aurez avant que la règle ne devienne définitive.

Références

• GitHub Changelog — pull_request_target blocked by default December 2 (2 novembre 2026)
• GitHub Docs — Controlling workflow execution