GitHub blockiert pull_request_target ab 2. Dezember standardmäßig in öffentlichen Repositories, mit Brownouts am 9. und 16. November

Am 2. November 2026 veröffentlichte GitHub einen Changelog-Eintrag, wonach GitHub Actions das Ereignis pull_request_target in allen öffentlichen Repositories standardmäßig blockiert, sofern keine anwendbare Actions-Ereignisrichtlinie es ausdrücklich erlaubt. Das Datum ist die wichtige Einzelheit. Der Eintrag besagt, die Durchsetzung sei zuvor für den 2. November 2026 geplant gewesen, und das neue Datum der dauerhaften Durchsetzung ist der 2. Dezember 2026. Der Eintrag ist als Abschaltung gekennzeichnet und gibt den Eigentümern öffentlicher Repositories ein kurzes Zeitfenster, um die Workflows zu finden, die nicht mehr laufen werden.

Der Grund ist Sicherheit. Das Ereignis pull_request_target läuft im Kontext des Basis-Repositorys und kann auf dessen Secrets zugreifen. Führt ein Workflow, der es nutzt, nicht vertrauenswürdigen Code aus einem Fork aus, könnte dieser Code die Pipeline kompromittieren oder Secrets stehlen. GitHub sagt, die Standardregel verringere dieses Risiko und lasse Eigentümer Workflows, die auf den Auslöser angewiesen sind, bewusst erlauben. Die Regel wurde über Schutzmaßnahmen für die Workflow-Ausführung eingeführt und läuft zunächst im Evaluierungsmodus, sodass Eigentümer sehen können, welche Workflow-Läufe sie blockieren würde, bevor die Durchsetzung beginnt.

Der Geltungsbereich ist wichtig, und der Eintrag formuliert ihn eng. Die Änderung gilt für öffentliche Repositories bei GitHub Free, GitHub Team und GitHub Enterprise Cloud. Sie gilt nicht für GitHub Enterprise Server. Private und interne Repositories sind nicht betroffen. Eine Organisation mit gemischten Repository-Arten sollte daher zuerst ihre öffentlichen Repositories auflisten, denn nur bei diesen kann ein Lauf blockiert werden.

Vor der dauerhaften Durchsetzung wendet GitHub den Standardschutz in zwei geplanten Brownouts tatsächlich an. Sie finden am 9. November 2026 und am 16. November 2026 statt, jeweils von 16:00 bis 18:00 UTC. In diesen Fenstern erzeugen Versuche, pull_request_target-Workflows auszuführen, die die Standardregel in betroffenen öffentlichen Repositories blockiert, fehlgeschlagene Läufe mit einer Fehlerannotation, und die Workflows werden nicht ausgeführt. Nach jedem Fenster kehrt die Regel in den Evaluierungsmodus zurück, und Workflows laufen wieder mit Warnungen. Ein Brownout ist für diese Workflows also ein echter Ausfall und keine Probe auf dem Papier.

Der Eintrag nennt zwei Wege. Vor dem ersten Brownout sollte man mit Insights prüfen, welche Workflow-Läufe die Regel blockieren würde. Dann behält man entweder die Standardregel, sodass der Auslöser blockiert bleibt, oder man erlaubt pull_request_target ausdrücklich in einer anwendbaren Actions-Ereignisrichtlinie, wenn Workflows darauf angewiesen sind, und erlaubt über die Zuordnung von Workflow-Dateien nur bestimmte Workflows. Das Ereignis für ein ganzes Repository zu erlauben, ist eine weitreichendere Entscheidung als die Erlaubnis für eine Datei, und der Eintrag verweist auf die Dokumentation zur Steuerung der Workflow-Ausführung.

Diese Dokumentation ergänzt Einzelheiten, die der Eintrag nicht wiederholt. Schutzmaßnahmen für die Workflow-Ausführung können einschränken, wer Workflows auslösen darf und welche Ereignisse laufen dürfen, und sie können eine Lockfile verlangen. Ereignisregeln betreffen Ereignisse wie push, pull_request, pull_request_target und workflow_dispatch. Bei Akteursregeln muss eine mit einer GitHub-Funktion verbundene Identität, etwa dependabot[bot], als erlaubter Akteur hinzugefügt werden, wenn sie Workflows ausführen soll. Die Dokumentation sagt, Richtlinien ließen sich auf Repository-, Organisations- und Unternehmensebene setzen, und empfiehlt mehrere klar definierte Richtlinien statt einer großen. Sie zeigt auch einen zu prüfenden Widerspruch. Die Seite sagt, wer für eine Richtlinie den Durchsetzungsstatus Evaluieren (Evaluate) wähle, könne in den Richtlinien-Einblicken beobachten, wann Nutzer an eine Einschränkung stoßen würden, und kennzeichnet Evaluate als nur für GitHub Enterprise Cloud verfügbar. Der Changelog sagt, die Standardregel starte in öffentlichen Repositories bei Free, Team und Enterprise Cloud im Evaluierungsmodus. Die Seiten erklären nicht, ob Eigentümer bei Free und Team dieselbe Insights-Ansicht erhalten; das sollte man in den eigenen Einstellungen prüfen, bevor man sich darauf verlässt.

Ein praktischer Plan ist kurz. Finden Sie jeden Workflow in öffentlichen Repositories, der pull_request_target verwendet. Entscheiden Sie bei jedem, ob er die Secrets oder Schreibrechte des Basis-Repositorys wirklich braucht oder ob pull_request genügt. Muss er bleiben, prüfen Sie, welchen Code er aus dem Fork auscheckt, denn das ist das gefährliche Muster, auf das die Regel zielt. Fügen Sie dann nur für diese Datei eine ausdrückliche Erlaubnis hinzu, halten Sie Verantwortlichen und Grund fest und testen Sie sie im Fenster am 9. November. Betrachten Sie den 2. Dezember als das Datum, ab dem eine fehlende Erlaubnisregel bedeutet, dass ein Workflow schlicht nicht läuft.