GitHub Actions blockiert pull_request_target standardmäßig: Frist auf den 2. Dezember verschoben

Am 2. November 2026 kündigte GitHub an, die standardmäßige Blockierung von Workflows, die
durch pull_request_target ausgelöst werden, in öffentlichen Repositorys auf den
2. Dezember zu verschieben. Die ursprünglich einen Monat früher gesetzte Frist gibt Teams mehr
Zeit, ihre Pipelines zu prüfen, bevor die Plattform einen Trigger, der regelmäßig mit
durchgesickerten Secrets in Verbindung gebracht wird, standardmäßig kappt. Die Änderung
betrifft die Pläne GitHub Free, Team und Enterprise Cloud und ist Teil einer Reihe von
Governance-Änderungen, die GitHub in diesem Herbst eingeführt hat.

#Was sich am 2. Dezember ändert

Ab dem 2. Dezember 2026 blockiert GitHub Actions standardmäßig pull_request_target-Ereignisse
in allen öffentlichen Repositorys, sofern eine Actions-Ereignisrichtlinie sie nicht
ausdrücklich erlaubt. Private und interne Repositorys sind von dieser Umstellung nicht
betroffen, ebenso wenig GitHub Enterprise Server-Instanzen.

#Warum dieser Trigger GitHub beunruhigt

Anders als pull_request führt der Trigger pull_request_target
den Workflow im Kontext des Basis-Repositorys aus und nicht im Kontext des ursprünglichen
Forks.

Dieser Trigger läuft im Kontext des Basis-Repositorys und kann auf dessen Secrets zugreifen.

Ein schlecht gebauter Workflow, der unvorsichtig Code aus einem Fork auscheckt und
ausführt, setzt dann die Tokens und Secrets des Haupt-Repositorys nicht vertrauenswürdigem
Code aus. Genau dieses seit Jahren in CI/CD-Sicherheitsberichten dokumentierte Muster will
GitHub mit dieser standardmäßigen Blockierung schließen.

#Wer betroffen ist, und wer nicht

#Zeitplan der Umstellung

Während der beiden Brownout-Fenster schlagen betroffene Läufe mit einer expliziten
Fehlerannotation fehl, wodurch sich genau erkennen lässt, welche Workflows vor der endgültigen
Frist korrigiert werden müssen.

#Wie man vor der Frist reagiert

Teams, die legitim auf pull_request_target angewiesen sind, etwa um einen
Kommentar zu einer Pull Request aus einem Fork zu posten, ohne jemals dessen Code auszuführen,
können dies über eine Actions-Ereignisrichtlinie, die auf die betreffenden Workflow-Dateien
zielt, ausdrücklich erlauben — im gleichen Geist wie
die jüngste Feinjustierung des CI-Cache-Zugriffs:

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

permissions:
  pull-requests: write

jobs:
  comment:
    runs-on: ubuntu-latest
    steps:
      # Kein Checkout des Fork-Codes: Es wird nur die API verwendet.
      - name: Kommentar posten
        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: "Danke für diesen Beitrag."
            })

#Was man sich merken sollte

Die standardmäßige Blockierung von pull_request_target in öffentlichen
Repositorys wird um einen Monat auf den 2. Dezember 2026 verschoben. Maintainer von
Open-Source-Projekten haben bis zum 9. November Zeit, ihre Workflows per Insights zu prüfen,
und dann bis zum 16. November, um die beiden Testfenster vor der endgültigen Umstellung zu
beobachten. Eine Actions-Ereignisrichtlinie erlaubt es, legitime Nutzungen des Triggers
fortzusetzen, ohne das Risiko durchgesickerter Secrets erneut einzuführen.

Zum Weiterlesen: die vollständige Ankündigung im
GitHub-Changelog.