GitHub Actions bloque pull_request_target par défaut : le couperet reporté au 2 décembre

GitHub a annoncé le 2 novembre 2026 le report au 2 décembre du blocage par défaut des
workflows déclenchés par pull_request_target sur les dépôts publics. L’échéance,
fixée un mois plus tôt, laisse davantage de temps aux équipes pour auditer leurs pipelines
avant que la plate-forme ne coupe par défaut un déclencheur régulièrement associé à des fuites
de secrets. La bascule concerne les offres GitHub Free, Team et Enterprise Cloud, et s’inscrit
dans une série de changements de gouvernance engagés par GitHub cet automne.

#Ce qui change le 2 décembre

À partir du 2 décembre 2026, GitHub Actions bloquera par défaut les événements
pull_request_target dans tous les dépôts publics, sauf si une politique
d’événements Actions les autorise explicitement. Les dépôts privés et internes ne sont pas
concernés par cette bascule, ni les instances GitHub Enterprise Server.

#Pourquoi ce déclencheur inquiète GitHub

Contrairement à pull_request, le déclencheur pull_request_target
exécute le workflow dans le contexte du dépôt de base plutôt que dans celui de la fork d’origine.

Ce déclencheur s’exécute dans le contexte du dépôt de base et peut accéder à ses secrets.

Un workflow mal construit, qui extrait et exécute du code provenant d’une fork sans précaution,
expose alors les jetons et secrets du dépôt principal à du code non fiable. C’est ce schéma,
documenté depuis plusieurs années dans des rapports de sécurité CI/CD, que GitHub cible avec ce
blocage par défaut.

#Qui est concerné, et qui ne l’est pas

#Calendrier de la transition

Pendant les deux fenêtres de « brownout », les exécutions concernées échouent avec une
annotation d’erreur explicite, ce qui permet de repérer précisément les workflows à corriger
avant l’échéance finale.

#Comment réagir avant l’échéance

Les équipes qui dépendent légitimement de pull_request_target, par exemple pour
publier un commentaire sur une pull request issue d’une fork sans jamais exécuter son code,
peuvent l’autoriser explicitement via une politique d’événements Actions ciblant les fichiers
de workflow concernés — dans le même esprit que
le réglage fin apporté récemment à l’accès au cache CI :

name: comment-on-fork-pr
on:
  pull_request_target:
    types: [opened, synchronize]

permissions:
  pull-requests: write

jobs:
  comment:
    runs-on: ubuntu-latest
    steps:
      # Pas de checkout du code de la fork : seule l'API est utilisée.
      - name: Poster un commentaire
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: "Merci pour cette contribution."
            })

#Ce qu’il faut retenir

Le blocage par défaut de pull_request_target sur les dépôts publics est reporté
d’un mois, au 2 décembre 2026. Les mainteneurs de projets open source ont jusqu’au 9 novembre
pour auditer leurs workflows via Insights, puis jusqu’au 16 novembre pour observer les deux
fenêtres de test avant la bascule définitive. Une politique d’événements Actions permet de
conserver les usages légitimes du déclencheur sans réintroduire le risque de fuite de secrets.

Pour aller plus loin : l’annonce complète sur le
changelog GitHub.