GitHub: Zwei Sicherheitsupdates für GitHub Actions schützen vor Pwn-Request-Angriffen

GitHub veröffentlichte am 18. Juni 2026 zwei sich gegenseitig ergänzende Sicherheitsupdates für GitHub Actions. Beide adressieren dasselbe grundlegende Problem: unkontrollierte Codeausführung aus nicht vertrauenswürdigen Quellen in der privilegierten Umgebung eines Repositorys.

Was ist ein Pwn Request und warum war er jahrelang ein Problem?

Ein Pwn Request ist ein Angriff, bei dem ein externer Mitwirkender einen Pull Request aus einem Fork öffnet und der ausgelöste Workflow ein privilegiertes Event nutzt — meistens pull_request_target —, das Zugang zu den Secrets des Basis-Repositorys gewährt. Im Gegensatz zum Standard-Event pull_request, das im isolierten Fork-Kontext läuft, wird pull_request_target im Kontext des Ziel-Repositorys ausgeführt und hat Zugang zu GitHub-Tokens und gespeicherten Secrets. Ein einziger solcher Angriff kann die gesamte CI/CD-Pipeline einer Organisation kompromittieren.

actions/checkout@v7: Sichere Standardeinstellungen auf Aktionsebene

Die neue Version der populären Checkout-Aktion führt Schutzverhalten als Standard ein: Bei privilegierten Events wie pull_request_target verweigert die Aktion das Abrufen von Code aus Fork-PRs und checkt stattdessen den Basis-Branch aus. Damit wird das häufigste Pwn-Request-Szenario ohne manuelle Konfiguration eliminiert. Für Teams, die das bisherige Verhalten für bestehende Workflows benötigen, steht ein Opt-out-Flag zur Verfügung. Ein Backport auf ältere Checkout-Versionen ist für den 16. Juli 2026 geplant.

Workflow Execution Protections: Schutz auf Organisationsebene

Parallel dazu hat GitHub Workflow Execution Protections in die öffentliche Vorschau eingeführt — einen administrativen Mechanismus, der die Definition von Allowlists nach Akteur und Eventtyp für die gesamte GitHub-Organisation ermöglicht. Im Gegensatz zu checkout@v7, das auf Ebene einzelner Workflow-Schritte schützt, greift diese Funktion, bevor der Workflow überhaupt mit der Ausführung beginnt. Administratoren können präzise festlegen, wer und welcher Eventtyp einen Workflow auslösen darf — externe Mitwirkende, Bots und unbekannte Akteure können systematisch ausgeschlossen oder bedingt zugelassen werden, ohne jeden einzelnen Workflow-Datei zu ändern.