LONDON (IT BOLTWISE) – GitHub macht den Checkout-Schritt in actions/checkout ab dem 18. Juni 2026 deutlich restriktiver: Bestimmte fork-basierte Pull-Requests werden in pull_request_target- und workflow_run-Kontexten blockiert, wenn typische pwn-request-Muster vorliegen. Damit soll verhindert werden, dass unreviewter Code im Kontext des Default-Branches mit dem voll privilegierten GITHUB_TOKEN sowie Secrets ausgeführt wird. Der Fix wird zudem laut Plan auf alle aktuell unterstützten major Versionen zurückportiert. Für Teams bedeutet das: Workflows müssen ihre Berechtigungen und Checkout-Logik genauer prüfen, statt auf „funktioniert schon“ zu setzen.
GitHub zieht an einer Stelle nach, an der in den letzten Monaten besonders viele Supply-Chain-Angriffe ansetzen: dem Zusammenspiel aus pull_request_target und dem Checkout-Schritt. In einem Update zu actions/checkout wird die Aktion ab 18. Juni 2026 so konfiguriert, dass sie die „Common Pwn Request“-Angriffsmuster standardmäßig ablehnt. Ausgelöst wird die Restriktion vor allem dann, wenn ein Workflow durch pull_request_target (oder in einem eingeschränkten Fall durch workflow_run) läuft und dabei Code aus einem Fork auscheckt, der dem System noch nicht durch Review vertrauenswürdig gemacht wurde.
Konkret betrifft die Änderung die offiziellen actions/checkout-Versionen: „actions/checkout v7“ verweigert den Fetch von Fork-Pull-Request-Head- und Merge-Commits in pull_request_target-Workflows, sowie in workflow_run nur dann, wenn das workflow_run.event mit pull_request* zusammenpasst. Der Checkout soll außerdem nicht passieren, wenn bestimmte Referenzen und Auflösungslogiken „auf die Forks hinauslaufen“: etwa wenn das repository auf den Fork auflöst, oder wenn das ref auf die typischen refs/pull/{number}/head– beziehungsweise refs/pull/{number}/merge-Pattern matcht. Eine Ausnahme ist nur per explizitem Opt-out vorgesehen.
Diese Opt-out-Mechanik ist bewusst eng gehalten: Workflow-Autoren können laut GitHub über das Flag allow-unsafe-pr-checkout mit Wert truerepository/ref am Ende tatsächlich auf den Fork-PR-Ref oder einen Fork-Merge-Commit zeigt. Damit adressiert GitHub eine häufige Angriffsoberfläche, bei der ein scheinbar harmloser Checkout-Schritt in Wahrheit Code aus nicht vertrauenswürdigen Quellen in einen privilegierten Runner-Kontext hineinzieht.
Der Kernrisiko-Mechanismus bleibt dabei unverändert und ist seit dem Aufkommen von pwn request wiederholt dokumentiert worden: pull_request_target läuft automatisch im Kontext des Default-Branches des Basis-Repositorys. Dadurch erhält der Workflow Zugriff auf Secrets und auf einen GITHUB_TOKEN, der typischerweise sowohl Lese- als auch Schreibrechte haben kann. Genau diese Kombination macht Angriffe so wirksam: Wenn ein böswilliger Akteur einen Pull Request mit schädlichem Code einbringt und der Workflow diesen Code anschließend via actions/checkout auscheckt und ausführt, können Angreifer Token und Geheimnisse exfiltrieren oder Berechtigungen zweckentfremden. GitHub nennt als mögliche Folgen unter anderem Cache-Poisoning und das ungewollte Erlangen von Schreibzugriffen.
Dass GitHub hier nicht nur theoretisch handelt, zeigt der Blick auf jüngere Vorfälle in der Software-Lieferkette. Besonders schwerwiegend waren Kampagnen wie die Kompromittierung mehrerer Pakete im Umfeld des Nx-Build-Systems (unter dem Code-Namen „s1ngularity“) sowie eine Reihe weiterer Breaches, darunter Vorfälle rund um PostHog, TanStack und ein populäres Emacs-Paket (kubernetes-el/kubernetes-el). Diese Ereignisse zeigen zwar nicht 1:1 denselben Pfad wie pull_request_target, aber sie bestätigen ein Muster: Angriffe sind dort besonders erfolgreich, wo Build- oder CI-Schritte unzureichend zwischen „untrusted input“ und „trusted execution“ trennen. Der neue Guardrail gegen unsichere Fork-Checkouts ist daher eher als gezielte Härtung eines bekannten Pfads zu verstehen als als komplette „CI-Security“-Lösung.
Technisch betrachtet setzt GitHub mit der Änderung an einer Stelle an, die die Angriffsfläche stark beeinflusst: actions/checkout entscheidet, was im Workspace des Runners landet. Der entscheidende Vergleich zur bisherigen Praxis liegt darin, dass bisher Workflows zwar im Sinne von pull_request_target eine „vertrauenswürdige“ Ausführung im Default-Branch implizierten, aber der Checkout-Schritt wiederum festlegen konnte, dass später doch Code aus dem Fork-PR ausgeführt wird. Andere CI-Ökosysteme verfolgen teils ähnliche Mechanismen (z. B. in Jenkins-Pipelines oder bei GitLab CI mit bestimmten „merge request“/„pipelines from forks“-Konzepten), aber die Sicherheitsimplikationen hängen stark von Standard-Defaults und von der Granularität der Berechtigungen ab. Hier unterscheidet sich GitHub in der aktuellen Maßnahme vor allem dadurch, dass die Härtung standardmäßig im offiziellen Checkout-Tool greift – also dort, wo viele Teams ohnehin starten.
Markt- und Wettbewerbsseite: Für Enterprise-Kunden und Security-Teams ist das Update weniger eine Frage der Features als der Governance. Wer heute nur auf „Workflow-Dateien sind reviewed“ schaut, übersieht leicht, dass die konkrete Codebasis, die im Runner landet, ein eigenständiges Vertrauensmodell braucht. In vergleichbaren Plattformen wie GitLab oder Bitbucket spielt die Trennung zwischen „pipeline trigger context“ und „code fetch context“ ebenfalls eine große Rolle; dort wird allerdings häufiger über projektweite Settings, Schutzregeln und Token-Scopes abgesichert. GitHub verlagert nun einen Teil dieser Verantwortung in die Bibliothek, die den Checkout ausführt. Das ist ein wichtiges Signal, weil es Sicherheitsrisiken nicht erst durch Schulung der Entwickler reduziert, sondern durch restriktive Standardparameter.
Für Teams mit bestehenden Workflows bedeutet die Änderung ab 18. Juni 2026 eine potenzielle Brechung: Wenn ein Workflow pull_request_target nutzt, um z. B. Kommentare oder Labeling automatisiert zu betreiben, aber dabei dennoch Code aus Forks auscheckt, wird er künftig in den betroffenen Fällen fehlschlagen. GitHub plant zudem laut Angaben den Backport auf alle aktuell unterstützten major Versionen für den 16. Juli 2026. In der Praxis werden viele Teams daher zwei Wege prüfen: entweder sie wechseln bei fehlendem Geheimnisbedarf zurück zu pull_request, oder sie reduzieren die Token-/Secret-Rechte so weit wie möglich und vermeiden das Ausführen von Fork-Code im privilegierten Kontext.
Damit rückt auch die Security-Disziplin im Umfeld von Berechtigungen und Datenflüssen stärker in den Fokus. Ein sicherer Ansatz besteht darin, Workflows in privilegierten Events grundsätzlich so zu gestalten, dass sie nur „vertrauenswürdige“ Artefakte verarbeiten, während die Ausführung von untrusted Code in einem getrennten, weniger privilegierten Schritt geschieht. GitHub nennt selbst, dass die Abdeckung der neuen Schutzlogik nur „Checkout via actions/checkout“ umfasst und damit ein Guardrail bleibt. Workflows, die Secrets, Write-Permissions, Deployment-Rechte oder OIDC-Publishing besitzen, müssen weiterhin sorgfältig bewertet werden. Genau hier passen Security-Policies aus Compliance-Sicht hinein: Unternehmen, die personenbezogene oder regulierte Daten verarbeiten, müssen ohnehin sicherstellen, dass Zugriffsrechte konsistent nach dem Prinzip der geringsten Privilegien vergeben werden.
Ausblick: Die Änderung wird Entwickler dazu zwingen, ihre CI/CD-Architekturen bewusster zu entkoppeln. Kurzfristig dürfte das zu mehr „Warum schlägt das bei Forks fehl?“-Ticketaufkommen führen – langfristig erhöht es aber die Erwartungshaltung, dass Runner-Execution und Code-Checkout nicht beliebig austauschbar sind. Ein sinnvoller nächster Schritt ist, in den Workflows explizit zu dokumentieren, ob wirklich ein privilegierter Event nötig ist und welche Datenflüsse über GITHUB_TOKEN und Secrets laufen. Wer so vorgeht, reduziert das Risiko ähnlich breitflächiger Supply-Chain-Schäden und schafft bessere Voraussetzungen für Audits, ohne Teams in der Entwicklung zu bremsen.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "GitHub stärkt actions/checkout gegen „pwn request“-Angriffe ab 18. Juni 2026" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "GitHub stärkt actions/checkout gegen „pwn request“-Angriffe ab 18. Juni 2026" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »GitHub stärkt actions/checkout gegen „pwn request“-Angriffe ab 18. Juni 2026« bei Google Deutschland suchen, bei Bing oder Google News!