Im Beitrag „Secrets-Scoping in GitHub Actions: Wer sieht was, und warum Fork-PRs leer ausgehen“ (23.09.2026) steht bereits ein eigener Abschnitt zu pull_request_target: der Trigger läuft im Kontext des Zielrepos statt des Forks, bekommt damit vollen Zugriff auf Secrets und potenzielle Schreibrechte, GitHub warnt dort vor dem Checkout nicht vertrauenswürdigen Codes, und beide Trigger teilen sich einen Cache. Was dort fehlt, und worum es hier geht: das konkrete Angriffsmuster dahinter, die Cache-Poisoning-Mechanik im Detail und GitHubs neue Default-Policy mit einem festen Durchsetzungstermin.
Wo die Sicherheit bricht: der Pwn Request
Die Lücke entsteht erst, wenn ein Workflow diesen Schutz selbst aushebelt, meist ungewollt. Wer im Checkout-Schritt eine ref auf den Kopf des Pull Requests setzt (etwa ref: ${{ github.event.pull_request.head.sha }}) und den ausgecheckten Code danach ausführt, zum Beispiel über ein Testkommando, einen Build-Schritt oder ein mitgebrachtes Skript, lässt fremden Code mit dem Token und den Secrets des Zielrepos laufen. GitHub nennt dieses Muster „pwn request“ und benennt es als Ursache mehrerer Supply-Chain-Kompromittierungen. Der Checkout allein ist noch nicht das Problem, die Ausführung danach ist es.
Cache Poisoning: der Read-only-Default, und was ihn aufhebt
Zusätzlich zum Secrets-/Schreibrechte-Risiko teilen sich pull_request_target-Workflows laut GitHub-Dokumentation denselben Cache wie andere privilegierte Trigger. Um Cache Poisoning einzugrenzen, bekommt ein solcher Workflow dort standardmäßig nur Lesezugriff: er kann bestehende Cache-Einträge nutzen, aber keine neuen schreiben oder überschreiben. Wer das über einen schreibfähigen Cache-Modus aufhebt, holt sich genau das Risiko zurück, das die Beschränkung verhindern soll: ein Fork-PR könnte dann einen manipulierten Cache-Eintrag hinterlegen, den ein späterer, privilegierter Lauf unbemerkt wiederverwendet.
GitHubs neue Default-Policy: ab 2. Dezember scharf
Stand heute, 10.11.2026: seit kurzem blockiert GitHub pull_request_target in öffentlichen Repositories standardmäßig über eine eigene Event-Policy, aktuell im Evaluate-Modus: betroffene Workflow-Läufe werden noch nicht gestoppt, erscheinen aber in den Policy Insights als Treffer. Ab dem 2. Dezember 2026 wird die Policy für Repositories scharf geschaltet, die bislang ohne eigene Event-Policy auf diesem Standardverhalten liefen. Wer den Trigger weiter braucht, muss ihn bis dahin über eine eigene Event-Policy explizit erlauben, sonst blockiert GitHub den Workflow nach der Umstellung ohne weitere Ankündigung.
Absicherung, wenn du pull_request_target wirklich brauchst
GitHub rät vorher zu zwei Fragen: Reicht pull_request, wenn kein zusätzlicher Secret-Zugriff nötig ist? Und wird der ausgecheckte Code irgendwann ausgeführt, auch nur über ein Build- oder Testkommando? Fällt die Antwort nicht klar zugunsten von pull_request_target aus, bleibt der Trigger riskant. Wer ihn trotzdem einsetzt, sollte die Berechtigungen des GITHUB_TOKEN auf das Minimum setzen; wie die tatsächliche Rechteberechnung dafür funktioniert, beschreibt der Artikel vom 04.11. zu GITHUB_TOKEN-Workflow-Permissions und Org-Base-Permission. Selbstgehostete Runner gehören dabei ausschließlich isoliert und flüchtig betrieben, der Artikel vom 09.07. zur Runner-Sicherheit zeigt, warum ein geteilter Pool das zusätzlich verschärft. Eine zusätzliche Freigabestufe über Environment Protection Rules mit Required Reviewers (ausführlicher im Beitrag vom 23.09.) bleibt sinnvoll, ersetzt aber keine der beiden vorherigen Maßnahmen. Für den seltenen Fall, in dem Checkout von PR-Code unvermeidbar bleibt, bietet actions/checkout das Flag allow-unsafe-pr-checkout, bewusst so benannt, dass es im Code-Review auffällt. Eine eigene Freigabepflicht für Änderungen an genau diesen Workflow-Dateien gehört in jedes Setup, das Fork-PRs überhaupt entgegennimmt: eine unauffällige Änderung an dieser einen Stelle reicht aus, um den gesamten Schutz zu unterlaufen.
Kontakt
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Pipeline-Berechtigungen und Workflow-Trigger modulweise gegen genau diese Risiken prüfen), AI Governance (Nachvollziehbarkeit dort schaffen, wo automatisierte Build- und Deployment-Schritte Freigaben verwischen) und Maintenance (laufende Prüfung, ob neue Workflow-Trigger die bestehende Härtung unterlaufen). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.
Kommentar verfassen