Aufschub für Actions-Nutzer: pull_request_target erst im Dezember gesperrt, davor Brownouts
Serguey Asael Shinder1 Min. LesezeitGitHub hat einen neuen Termin für das standardmäßige Blockieren des Ereignisses pull_request_target in öffentlichen Repositories festgelegt. Ab dem 2. Dezember 2026 blockiert GitHub Actions diese Ereignisse, sofern keine Actions-Ereignisrichtlinie sie ausdrücklich erlaubt. Zuvor war die Durchsetzung für den 2. November angesetzt. Private und interne Repositories sind nicht betroffen; die Änderung gilt für GitHub Free, Team und Enterprise Cloud, nicht für Enterprise Server.
Die Regel gehört zu den Schutzmechanismen für die Workflow-Ausführung und läuft derzeit im Bewertungsmodus, der zeigt, welche Läufe sie blockieren würde. Bevor sie dauerhaft greift, schaltet GitHub sie in zwei Brownouts ein, am 9. und 16. November, jeweils von 16:00 bis 18:00 UTC. In diesen Fenstern schlagen blockierte pull_request_target-Läufe in betroffenen öffentlichen Repositories mit einer Fehlermeldung fehl, die Workflows werden nicht ausgeführt; danach kehrt die Regel in den Bewertungsmodus zurück, und Läufe gehen mit Warnungen weiter.
Den Grund nennt GitHub selbst: pull_request_target läuft im Kontext des Basis-Repositorys und kann dessen Secrets lesen. Ein Workflow, der nicht vertrauenswürdigen Code aus einem Fork ausführt, liefert diesem Code damit die Pipeline aus. Maintainer können die Standardsperre behalten oder den Auslöser in einer Ereignisrichtlinie ausdrücklich erlauben und auf einzelne Workflow-Dateien beschränken.
Was das bedeutet
Jedes öffentliche Repository mit Workflows auf pull_request_target sollte vor dem 9. November die Insights-Ansicht prüfen. Die Brownouts sind der günstige Moment dafür: Ein fehlgeschlagener Lauf an einem Montagnachmittag ist besser als eine kaputte Release-Pipeline im Dezember, und die Abhilfe ist entweder ein Richtlinieneintrag oder ein Workflow, der den Auslöser nicht mehr braucht.