GitHub Actions: pull_request_target ab 2. Dezember standardmäßig blockiert, erste Testabschaltungen am 9. November
Ab dem 2. Dezember 2026 blockiert GitHub den Trigger pull_request_target standardmäßig in allen öffentlichen Repositories. Zuvor führen zwei zweistündige Testabschaltungen am 9. und 16. November von 17:00 bis 19:00 Uhr (Pariser Zeit) dazu, dass betroffene Workflows fehlschlagen.
Wenn Sie ein öffentliches Repository auf GitHub verwalten, das den Trigger pull_request_target verwendet, sollten Sie sich diesen Termin vormerken: An diesem Montag, dem 9. November, von 17:00 bis 19:00 Uhr (Pariser Zeit) könnten Ihre Workflows fehlschlagen. Dies ist die erste von zwei angekündigten Testabschaltungen seitens GitHub vor der standardmäßigen Blockierung dieses Triggers am 2. Dezember 2026 in allen öffentlichen Repositories (Changelog).
Warum dieser Trigger im Fokus steht
pull_request_target dient vor allem dazu, Reaktionen auf Pull Requests aus Forks zu automatisieren: Zuweisung von Labels, Triage, Kommentare, Statusmeldungen. Seine Besonderheit: Er wird im Kontext des Basis-Repositories ausgeführt – mit Zugriff auf dessen Secrets und ein Token mit Schreibrechten. Solange der Workflow ausschließlich Code aus dem Standard-Branch ausführt, besteht keine Gefahr. Wird jedoch Code aus dem Pull Request ausgecheckt und ausgeführt, kann eine böswillige Person die Integrationspipeline kompromittieren oder Secrets stehlen. Das ist der von GitHub angeführte Grund, dessen Dokumentation warnt: Ein auf diese Weise ausgelöster Workflow darf niemals Code aus einem nicht vertrauenswürdigen Pull Request bauen oder ausführen, während Zugriff auf Secrets besteht.
Der Zeitplan
- Bis zum 2. Dezember: Die Standardregel läuft im Evaluierungsmodus, Workflows werden mit Warnungen ausgeführt.
- 9. und 16. November, 16:00–18:00 Uhr UTC (17:00–19:00 Uhr Pariser Zeit): Vorübergehende Blockierung. Betroffene Workflows erzeugen fehlgeschlagene Ausführungen mit einer Fehlerannotation.
- 2. Dezember: Dauerhafte Standardblockierung, sofern keine explizite Autorisierung vorliegt. Die ursprüngliche Frist war der 2. November.
Betroffen sind öffentliche Repositories auf GitHub Free, Team und Enterprise Cloud. Private und interne Repositories sowie GitHub Enterprise Server sind davon ausgenommen.
Was vor Montag zu tun ist
GitHub rät dazu, die Insights zu öffnen, um potenziell blockierte Ausführungen zu identifizieren. Danach gibt es drei Optionen: Benötigt der Workflow weder Secrets noch Schreibrechte, sollte auf den Trigger pull_request umgestellt werden; werden diese zwingend benötigt, kann er über eine Actions-Ereignisrichtlinie gezielt für diese eine Workflow-Datei autorisiert werden – wobei sicherzustellen ist, dass niemals Code aus dem Pull Request ausgeführt wird; andernfalls lässt man die Blockierung einfach greifen.
Unsere Einschätzung
pull_request_target ist eine wohlbekannte Falle für Maintainer, da die Grenze zwischen „auf einen Pull Request reagieren“ und „dessen Code ausführen“ schnell versehentlich überschritten wird. Den Standardwert umzukehren, ist die richtige Entscheidung, und die Testabschaltungen verhindern böse Überraschungen am Tag der Umstellung. Die Relevanz steigt zusätzlich durch Coding-Agenten, die in großem Stil Pull Requests für öffentliche Projekte öffnen: Je mehr automatisierte Beiträge eingehen, desto eher wird ein zu permissiver Workflow zum Angriffsziel. Für Maintainer ist der Aufwand gering, sollte aber sofort erledigt werden: Ein paar Minuten in den Insights ersparen einen Abend voller rot leuchtender CI-Pipelines.
Quellen
- GitHub Changelog — pull_request_target blocked by default December 2 (2. November 2026) Primärquelle
- GitHub Docs — Securely using pull_request_target Primärquelle
Eine Primärquelle stammt direkt von dem betreffenden Unternehmen, Labor oder der Organisation. Eine Sekundärquelle gibt die Information wieder, ohne ihr Urheber zu sein: Wir kennzeichnen sie als solche. Einen Fehler entdeckt? Lesen Sie unsere Korrekturrichtlinie.
