GitHub blockiert pull_request_target in öffentlichen Repositories standardmäßig
Eine GitHub-Actions-Regel betrifft privilegierte Pull-Request-Workflows. So können sich Teams auf die Durchsetzung vorbereiten.
Mehr als ASPM
Proof-Driven AppSec für Teams, die mit KI entwickeln
Plexicus nutzt AI Swarm Pentest, um autorisierte Anwendungspfade zu erkunden, ausnutzbare Risiken zu validieren und Teams Belege für die Priorisierung der Remediation zu geben.
AI Swarm Pentest ansehenAb dem 2. Dezember 2026 will GitHub pull_request_target-Ereignisse in öffentlichen Repositories standardmäßig blockieren, sofern keine geltende Actions-Ereignisrichtlinie sie ausdrücklich erlaubt. Zuvor gibt es zwei vorübergehende Durchsetzungsfenster. Die Regel schützt eine sensible Grenze und kann zugleich erwartete Workflows unterbrechen.
Termine und Geltungsbereich
GitHub veröffentlichte den aktualisierten Zeitplan am 2. November. Vor der dauerhaften Durchsetzung läuft die Regel im Evaluierungsmodus: Außerhalb der Zeitfenster können betroffene Workflows mit Warnungen laufen.
| Datum | Ereignis |
|---|---|
| 9. November 2026, 16–18 UTC | Erstes vorübergehendes Durchsetzungsfenster |
| 16. November 2026, 16–18 UTC | Zweites vorübergehendes Durchsetzungsfenster |
| 2. Dezember 2026 | Beginn der standardmäßigen Blockierung |
Während der Zeitfenster schlägt ein blockierter Lauf mit einer Fehlermeldung fehl; der Workflow wird nicht ausgeführt. Die Regel gilt für öffentliche Repositories auf GitHub Free, Team und Enterprise Cloud. Laut GitHub sind private und interne Repositories sowie GitHub Enterprise Server nicht von dieser Regel betroffen.
Warum dieses Ereignis wichtig ist
pull_request_target läuft im Kontext des Basis-Repositories. Laut GitHubs Sicherheitsleitfaden können privilegierte Workflows auf Schreibberechtigungen, referenzierte Secrets und den Cache des Hauptbranches zugreifen. Wird nicht vertrauenswürdiger Pull-Request-Inhalt in diesem Kontext ausgecheckt und ausgeführt, können Pipeline oder Secrets gefährdet werden.
Der Name des Triggers allein beweist keine ausnutzbare Schwachstelle. Prüfen Sie, welche Codes, Skripte und Artefakte tatsächlich verarbeitet werden, welche Berechtigungen und Secrets verfügbar sind und ob Fork-Beiträge die Eingaben beeinflussen können. GitHub empfiehlt außerdem Vorsicht bei Artefakten aus nicht vertrauenswürdigen Läufen in einem workflow_run-Workflow.
Vor dem ersten Zeitfenster
- Identifizieren Sie mit Insights die Läufe, die die Regel blockieren würde, und ordnen Sie jedem Workflow eine verantwortliche Person zu.
- Prüfen Sie, ob der Job das privilegierte Ereignis benötigt. Für nicht vertrauenswürdigen Code kann ein
pull_request-Workflow mit minimalen Berechtigungen geeignet sein. Testen Sie Forks und Repository-Einstellungen; ein anderer Trigger ersetzt keine Sicherheitsprüfung. - Falls der privilegierte Workflow nötig ist, führen Sie keinen nicht vertrauenswürdigen Code aus, begrenzen Sie Rechte und prüfen Sie Artefaktgrenzen. GitHub dokumentiert die Steuerung der Workflow-Ausführung.
- Behalten Sie die Standardsperre möglichst bei. Falls das Ereignis nötig ist, bietet GitHub explizite Ereignisrichtlinien für ausgewählte Workflows. Prüfen Sie jede Ausnahme: Eine Erlaubnis macht die Eingabe nicht vertrauenswürdig.
- Testen Sie vor dem 9. November kontrolliert und benennen Sie eine verantwortliche Person sowie einen Rücknahmeplan.
Entscheidung und Nachweis verbinden
Die Richtlinie entscheidet, ob ein Workflow starten darf. Die Sicherheitsprüfung muss zusätzlich festhalten, was er ausführt und welche Zugangsdaten er erreichen kann: Workflow-Version, Ereignisquelle und beobachtetes Ergebnis.
Plexicus AI Swarm Pentest beschreibt eine nachweisgestützte Validierung autorisierter Anwendungen und APIs; remediation unterstützt prüfbare Korrekturen validierter Anwendungsbefunde. Nutzen Sie diese Abläufe neben einer separaten GitHub-Actions-Prüfung: Ein Anwendungsscan allein belegt keine sichere Workflow-Richtlinie.
Prüfen Sie betroffene Repositories vor dem ersten Zeitfenster. Plexicus remediation ansehen.
Bild: Aufnahme eines Originalabsatzes aus GitHub Docs, Secure use reference, unter CC BY 4.0. Dies stellt keine Unterstützung dar.
