Ab dem 2. Dezember 2026 blockiert GitHub den Trigger pull_request_target in allen öffentlichen Repositories standardmäßig. Eine zutreffende Actions Event Policy kann ihn ausdrücklich erlauben. Ursprünglich sollte die Regel am 2. November 2026 greifen; GitHub hat den Termin um einen Monat verschoben.
Die Regel gehört zu den Workflow Execution Protections. Sie startet im Evaluate-Modus. GitHub protokolliert dann, welche Workflow-Läufe die Regel blockieren würde, stoppt sie aber nicht. Wer den Trigger heute in öffentlichen Repositories nutzt, hat so eine Beobachtungsphase. Private und interne Repositories sind nicht betroffen.
Warum pull_request_target ein Sicherheitsrisiko ist
Ein pull_request-Workflow läuft im Kontext des Forks. Er sieht den Code des Beitragenden, aber nicht die Secrets des Zielprojekts. pull_request_target läuft im Kontext des Basis-Repositories, also des Projekts, in das der Pull Request gemergt werden soll. Dieser Kontext kann auf die dort hinterlegten Secrets zugreifen.
Soll ein Workflow einen Kommentar zum Pull Request posten oder Labels setzen, ist der Basis-Kontext nützlich. Führt er dabei Code aus dem Fork aus, wird es riskant: Fremder, ungeprüfter Code läuft in einer Umgebung mit Zugriff auf vertrauliche Werte. Ein Angreifer müsste nur einen Pull Request stellen, dessen Inhalt beim Ausführen etwas anderes tut als erwartet. So lassen sich Zugangsdaten abgreifen oder die Pipeline kompromittieren. Die neue Standardregel soll das Risiko verkleinern, ohne den Trigger pauschal unbrauchbar zu machen.
Brownouts im November: zwei Testfenster
Vor der dauerhaften Durchsetzung testet GitHub die Regel in zwei begrenzten Fenstern, sogenannten Brownouts. In diesen Fenstern ist die Standardschutzregel vorübergehend aktiv. Betroffene Workflow-Versuche in öffentlichen Repositories werden nicht ausgeführt; sie erzeugen fehlgeschlagene Läufe mit einer Fehlerannotation. Das erste Fenster liegt am 9. November 2026 von 16:00 bis 18:00 UTC, das zweite am 16. November 2026 zur selben Uhrzeit.
Nach jedem Fenster kehrt die Regel in den Evaluate-Modus zurück. Workflows laufen wieder, erzeugen aber Warnhinweise. Diese Warnungen zeigen, welche Workflows bei dauerhafter Durchsetzung betroffen wären. Wer die zwei Stunden im November verstreichen lässt, ohne die Hinweise zu prüfen, bekommt im Dezember blockierte Läufe statt einer rechtzeitigen Warnung.
Betroffene Workflows vorab prüfen und vorbereiten
Die Insights-Ansicht zeigt, welche Workflow-Läufe die Regel blockieren würde. Diese Prüfung sollte vor dem ersten Brownout am 9. November abgeschlossen sein. Dann bleibt Zeit, Policies anzupassen oder Workflows umzubauen. Wer erst im Dezember auswertet, arbeitet schon mit blockierten Läufen.
Danach gibt es zwei Wege. Der erste: Die Standardregel bleibt bestehen, pull_request_target wird also blockiert. Das ist die sichere Variante für Projekte, die den Trigger nicht brauchen. Der zweite: Eine zutreffende Actions Event Policy erlaubt den Trigger ausdrücklich. Das passt für Workflows, die auf pull_request_target angewiesen sind, etwa weil sie im Basis-Kontext Kommentare setzen oder Labels verwalten. Mit Workflow File Targeting lässt sich die Freigabe auf bestimmte Workflow-Dateien begrenzen, statt sie für das ganze Repository zu öffnen.
Wer betroffen ist und wer nicht
Die Änderung gilt für öffentliche Repositories auf GitHub Free, GitHub Team und GitHub Enterprise Cloud. GitHub Enterprise Server ist ausgenommen, ebenso private und interne Repositories auf allen Plänen. Wer nur in geschlossenen Umgebungen arbeitet, muss nichts umstellen. Für Open-Source-Projekte und öffentliche Werkzeugsammlungen ist die Änderung relevant, sobald pull_request_target verwendet wird.
Die Verschiebung vom 2. November auf den 2. Dezember bringt einen zusätzlichen Monat im Evaluate-Modus. Gleichzeitig liegen die Brownouts näher an der endgültigen Durchsetzung. Zwischen dem letzten Testfenster am 16. November und dem Stichtag am 2. Dezember bleiben nur rund zwei Wochen für Anpassungen.
Was sich für den Betrieb ändert
Die Änderung schafft den Trigger nicht ab, sie dreht die Voreinstellung um. Bisher galt pull_request_target als verfügbar, solange niemand etwas anderes konfigurierte. Künftig muss die Nutzung aktiv freigegeben werden. Workflow Execution Protections sollen verhindern, dass riskante Standardeinstellungen unbemerkt zum Dauerzustand werden.
Für Betreiber eines öffentlichen Repositories heißt das: Prüfe in den Insights, ob die Regel etwas blockieren würde. Wenn nicht, kannst du die Standardeinstellung lassen und musst nichts weiter tun. Findest du betroffene Workflows, entscheide, ob du sie auf eine sicherere Variante umstellst oder die Freigabe eng erteilst. Actions Event Policy und Workflow File Targeting erlauben eine gezielte Steuerung, statt den Trigger für alle Workflows im Repository zu öffnen.
Der 9. November ist der erste Prüftermin. Wer die Brownouts nutzt, sieht die Blockade zweimal kontrolliert und kann nachbessern. Wer sie ignoriert, sieht sie im Dezember unkontrolliert. Dann fallen unter Umständen Workflows aus, die niemand mehr auf dem Zettel hatte.
Quelle: github.blog
