Konkret erklärt GitHub, dass „actions/checkout v7“ das Abrufen von Code aus Pull Requests aus Forks in „pull_request_target“- und „workflow_run“-Workflows verweigert. Für „workflow_run“ gilt das nur dann, wenn „workflow_run.event“ ein „pull_request*“-Ereignis ist. Die Sperre greift standardmäßig, sofern Autorinnen und Autoren von Workflows sie nicht ausdrücklich deaktivieren, indem sie in „actions/checkout“ das Kennzeichen „allow-unsafe-pr-checkout“ auf „true“ setzen.
GitHub zielt damit auf die aus seiner Sicht häufigste Form von Pwn-Request-Angriffen im Actions-Ökosystem. Die Folge: „actions/checkout“ schlägt bei „pull_request_target“-Ereignissen aus Forks fehl, wenn unsichere Eingaben vorliegen. Der Auslöser „pull_request_target“ wird automatisch ohne manuelle Freigabe gestartet, wenn ein Pull Request geöffnet, erneut geöffnet oder sein Head-Branch aktualisiert wird. Er läuft im Kontext des Standard-Branches des Ziel-Repositorys und kann dadurch Geheimnisse sowie einen privilegierten GITHUB_TOKEN mit Lese- und Schreibrechten verfügbar machen.
GitHub warnt in seiner Dokumentation ausdrücklich davor, nicht vertrauenswürdigen Code über „pull_request_target“ auszuführen. Genannt werden unter anderem Cache-Vergiftung sowie unbeabsichtigter Zugriff auf Schreibrechte oder Geheimnisse. Das Risiko entsteht insbesondere dann, wenn „pull_request_target“ mit „actions/checkout“ kombiniert wird, um von einem nicht vertrauenswürdigen Fork eingereichten Code herunterzuladen und auszuführen. Reicht ein Angreifer einen Pull Request mit schädlichen Skripten ein und der Workflow checkt diesen Code aus und startet ihn, kann das laut GitHub zum Diebstahl des GITHUB_TOKEN und weiterer Geheimnisse führen — genau dieses Muster wird als Pwn-Request-Angriff bezeichnet.
In den vergangenen Monaten wurde dieses Verhalten nach Angaben des Quelltexts bereits in mehreren Angriffen auf die Software-Lieferkette ausgenutzt. Als schwerwiegendster Fall wird die Kompromittierung mehrerer Pakete rund um das Build-System Nx in einer Kampagne mit dem Codenamen s1ngularity genannt. Ebenfalls erwähnt werden Vorfälle bei PostHog, TanStack und dem verbreiteten Emacs-Paket „kubernetes-el/kubernetes-el“.
Auch Socket ordnet die Schwachstelle des Musters ein: „pull_request_target“ sei für vertrauenswürdige Automatisierung rund um Pull Requests gedacht, etwa zum Setzen von Labels, für Kommentare oder zum Anwenden von Projekt-Metadaten. Entscheidend sei aber der Checkout-Schritt, weil er festlege, welcher Code tatsächlich im Arbeitsbereich des Runners landet. Wenn dabei Code aus einem Pull Request aus einem Fork geholt werde, könne der Workflow am Ende von Angreifern kontrollierten Code mit den Rechten des Basis-Repositorys ausführen.
GitHub grenzt die Änderung zugleich klar ein. Pwn-Requests, die über andere Ereignistypen als „pull_request_target“ ausgelöst werden, etwa „issue_comment“, oder über andere Wege wie „git“ oder die GitHub-Befehlszeile, fallen nicht unter diese Anpassung. Blockiert werden nur Checkouts des Heads eines Pull Requests aus einem Fork sowie von Merge-Commits aus diesem Kontext. Nicht blockiert wird dagegen das Auschecken anderer nicht vertrauenswürdiger Repositories; als Beispiel nennt GitHub die Angabe von „repository:“ auf ein unabhängiges Drittanbieter-Repository.
Socket betont deshalb, der Schutz decke nur Checkouts ab, die über „actions/checkout“ erfolgen. Das sei eine Leitplanke, aber keine vollständige Lösung für die Sicherheit von Actions. GitHub rät Entwicklerinnen und Entwicklern daher, „pull_request_target“ nur bei Bedarf einzusetzen, andernfalls auf „pull_request“ zu wechseln, Berechtigungen für Workflows einzuschränken und sicherzustellen, dass von Nutzerinnen und Nutzern kontrollierte Eingaben nicht zur Ausführung nicht vertrauenswürdigen Codes führen.