GitHub schaltet pull_request_target am 2. November in öffentlichen Repos ab
Die Execution Protections für GitHub Actions haben diese Woche die Vorschau verlassen, und was in den Kalender gehört, ist nicht die Funktion, sondern das Datum: Ab dem 2. November 2026 wird in betroffenen öffentlichen Repositories eine Standardregel durchgesetzt, die den Trigger pull_request_target abschaltet. Bis dahin läuft sie im Evaluate-Modus — welche Läufe scheitern werden, ist also längst sichtbar, wenn man nachsieht.
Die Funktion selbst ist eine Positivliste für Workflow-Läufe: Actor-Regeln bestimmen, wer einen Workflow auslösen darf, Event-Regeln, welche Ereignisse ihn starten dürfen, und beides wird vor dem Lauf ausgewertet. Mit der allgemeinen Verfügbarkeit kommen drei Dinge hinzu, die daraus statt eines Schalters eine Richtlinie machen: Regeln lassen sich auf einzelne Workflow-Dateien statt auf ganze Repositories beziehen — deploy.yml nur für ein Team, CI weiter offen für alle; eine Insights-Ansicht zeigt, wie die Regeln in der Organisation greifen; und eine REST-API legt Regeln auf Ebene von Unternehmen, Organisation und Repository an, liest, ändert und löscht sie. Letzteres ist das, was man braucht, wenn die Antwort über Hunderte Repositories hinweg dieselbe sein soll.
Warum ausgerechnet pull_request_target
Weil es der Trigger ist, der mit den Secrets des Basis-Repositories läuft, während der geprüfte Code aus einem Fork stammt. Genau diese Kombination trägt die Angriffsklasse der Pwn Requests: nicht vertrauenswürdiger Code läuft in einem privilegierten Kontext und nimmt mit, was der Job lesen kann. Die Standardregel greift nur bei öffentlichen Repositories ohne eigene passende Event-Richtlinie; private und interne bleiben unberührt.
Was das bedeutet
Den Evaluate-Modus jetzt auswerten, nicht Ende Oktober. Die Regel sagt bereits, welche Läufe blockiert würden. Es am 2. November zu erfahren heißt, eine kaputte Pipeline nach fremdem Zeitplan zu reparieren — dieselbe Fehlerform wie bei jeder stillen Änderung einer Voreinstellung, nur dass diese sich sechs Wochen vorher angekündigt hat.
Dann pro Workflow entscheiden, nicht pro Repository. Es gibt zwei ehrliche Antworten. Entweder der Workflow braucht pull_request_target nicht — die meisten brauchen es nicht, und der übliche Umbau ist pull_request plus ein getrennter privilegierter Job — oder er braucht es wirklich, dann erlaubt die neue Zuordnung auf Dateiebene genau diese eine Datei, während die Sperre überall sonst stehen bleibt. Zu vermeiden ist, den Trigger für das ganze Repository wieder freizugeben, weil ein einziger Workflow gemeckert hat.
Und noch eine allgemeine Beobachtung. GitHub liefert hier weniger eine neue Schutzfunktion als eine neue Richtung für den nicht gesetzten Wert — für Repositories, deren Betreiber nie eine Präferenz geäußert haben. Das ist die wirksamste Sicherheitsänderung, die eine Plattform vornehmen kann, und zugleich diejenige, die im großen Maßstab am ehesten leise etwas zerbricht. Genau deshalb sind der Schattenmodus und die sechs Wochen Vorlauf das interessante Stück Technik — nicht die Positivliste.