BERLIN / LONDON (IT BOLTWISE) – GitHub bringt ein Sicherheits-Update für „actions/checkout“, das typische pwn-request-Angriffsmuster in „pull_request_target“-Workflows von Forks automatisch blockiert. Betroffen ist vor allem die Kombination aus privilegiertem GITHUB_TOKEN und dem Auschecken von Code aus nicht überprüften Pull Requests. Die Änderung startet am 18. Juni 2026 und soll bis 16. Juli 2026 auf alle unterstützten Major-Versionen zurückpropagiert werden. Damit schafft GitHub einen wichtigen „Guardrail“, ohne die generelle Notwendigkeit sorgfältiger Workflow-Prüfung zu ersetzen.
GitHub zieht bei der Software-Supply-Chain in Actions die nächste Sicherheitsleine enger: Das offizielle „actions/checkout“ wird so angepasst, dass es in bestimmten „pull_request_target“-Szenarien von Forks gar nicht erst den typischen Angriffsweg öffnet. Hintergrund ist die seit Jahren bekannte Klasse von „pwn request“-Mustern, bei denen untrusted Code im Kontext eines privilegierten Workflows ausgeführt wird. Gerade „pull_request_target“ ist dafür berüchtigt, weil der Event im Kontext des Default Branch der Base-Repository läuft und damit ein besonders mächtiges GITHUB_TOKEN sowie Zugriff auf Secrets und Cache-Mechanismen mitbringt.
Die technische Änderung greift ab dem 18. Juni 2026: In der aktuellen „actions/checkout“-Version verweigert das Action-Framework standardmäßig den Checkout von Fork-Pull-Request-Code, sobald die Eingaben in die bekannten Muster fallen. Konkret betrifft die Sperre Fork-Quellen, wenn das „ref“-Mapping auf „refs/pull/number/head“ oder „refs/pull/number/merge“ zeigt oder wenn der bereitgestellte Ref auf einen Head- oder Merge-Commit-SHA aus dem Fork auflöst. GitHub nennt diese Verweigerung „common pwn request patterns“; wer Workflows betreibt, muss damit rechnen, dass bestimmte bestehende Setups in „pull_request_target“-Pipelines nicht mehr automatisch funktionieren.
Für die Umsetzung ist entscheidend, wie GitHub Actions das Checkout step-basiert orchestriert: „pull_request_target“ startet ohne manuelle Freigabe, wenn ein Pull Request geöffnet oder aktualisiert wird. Dadurch entsteht ein Zeitfenster, in dem ein Angreifer sehr zielgerichtet Code einreichen kann, während der Workflow bereits im privilegierten Kontext läuft. Wenn „actions/checkout“ dann den Fork-Code in den Runner-Arbeitsbereich lädt, kann Schadcode so ausgeführt werden, dass das Token des Base-Repositories missbraucht wird. GitHub verweist dabei explizit auf Risiken wie Cache Poisoning sowie das ungewollte Erteilen von Lese-/Schreibrechten auf Secrets und Schreibberechtigungen.
Damit ordnet sich die Maßnahme in eine breitere Sicherheitsentwicklung ein, die in den letzten Monaten bei mehreren Ökosystemen sichtbar wurde: Neben der seit Jahren etablierten „Dependency“-Risikoanalyse rückten Angriffe durch Pipeline-Mechaniken stärker in den Fokus. Als prominentes Beispiel werden in der Branche Kampagnen genannt, die mit Manipulationen im Umfeld populärer Build-Systeme und Pakete arbeiteten, einschließlich der bekannten Nx-Verstrickungen aus einer Kampagne namens „s1ngularity“ sowie Vorfälle rund um PostHog, TanStack und ein Emacs-Paket („kubernetes-el/kubernetes-el“). Der gemeinsame Nenner ist: Ein kompromittierter Pfad im Build- oder Deploy-Prozess ist häufig schwerer zu erkennen als ein einzelnes fehlerhaftes Paket.
Wie begrenzt GitHub diesen Guardrail aus Sicht der Angreifer? GitHub stellt klar, dass die Sperre nicht „alle“ untrusted Repositories pauschal blockiert, sondern spezifisch Checkouts aus Fork-Pull-Request-Head- und Merge-Komponenten im Kontext von „pull_request_target“ verhindert. Andere event types sind explizit nicht im Scope, etwa „issue_comment“ oder Fälle, in denen Code über „git“ beziehungsweise die GitHub CLI geladen wird. Außerdem bleibt ein explizites Opt-out möglich: Wer den Checkout trotz Risiko erzwingen will, kann über das Flag „allow-unsafe-pr-checkout: true“ arbeiten. In der Praxis bedeutet das: Die meisten Teams profitieren von der Standardhärtung, aber sicherheitskritische Workflows müssen weiter dokumentieren, warum sie abweichende Regeln brauchen.
Für die Einordnung lohnt der Blick auf den Wettbewerb im CI/CD-Umfeld. GitLab CI, Jenkins und andere Systeme haben ebenfalls mechanisms für Branch-/Merge-Request-Kontexte und Token-Scopes, die je nach Plattform unterschiedlich fein granular ausrollbar sind. Der Trend ist jedoch identisch: Betreiber müssen die Privilegien von Runner-Jobs an den Vertrauensgrad der Eingaben koppeln. In GitHub-Ökosystemen ist das besonders sichtbar, weil Actions durch die Kombination aus Event-Trigger, Permission-Settings und Step-Ausführungen sehr „programmatisch“ werden kann. Branchenexperten empfehlen daher, bei allen Workflows mit erhöhten Rechten (Secrets, Deployment Permissions, OIDC-Publishing) nicht nur „welche“ Actions laufen lassen, sondern „welcher Kontext“ diese ausführt.
Regulatorisch und organisatorisch ist das Update ebenfalls relevant, weil es in die gängigen Security-Kontrollrahmen einzahlt: Viele Unternehmen erwarten aus Compliance- oder Risk-Gründen eine nachweisbare Minimierung von Berechtigungen (Least Privilege) sowie eine klare Abgrenzung zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code. „pull_request_target“ steht konzeptionell in Spannung dazu, da es die Base-Kontextrechte aktiviert, obwohl der Code aus einem Fork stammen kann. Das neue Verhalten reduziert zwar ein konkretes Angriffsdesign, ersetzt aber keine generische Governance: Teams sollten Permissions pro Workflow auf das Minimum setzen, Secrets strikt kapseln und in Kritikalitätsfällen Pull Requests konsequent über „pull_request“-Events laufen lassen, sofern keine erhöhten Rechte erforderlich sind.
Aus technischer Perspektive ist die Maßnahme ein gutes Beispiel für „Guardrails“ statt kompletten Ersatz: „actions/checkout“ wird nicht zu einem allwissenden Sicherheitsscanner, sondern blockiert konkrete Eingaben, die typischerweise zu Token-Exfiltration und Ausführung untrusted Code führen. Damit bleibt die Risikoanalyse auf der Workflow-Ebene: Werden in einem Job Artefakte gebaut, werden Deployment-Schritte ausgeführt, oder werden Cache-Mechanismen genutzt, die für Poisoning missbraucht werden könnten? GitHub betont zudem, dass die Schutzwirkung genau auf Checkouts über „actions/checkout“ beschränkt ist; wenn Workflows alternativ Repository-Inhalte per Script nachladen, können die gleichen Risiken weiterhin bestehen.
Wie sollten Teams jetzt vorgehen? Erstens lohnt ein gezielter Audit der Workflows, die „pull_request_target“ nutzen, insbesondere dort, wo im Job-Plan „actions/checkout“ vorkommt oder parallel über git/Cli nachgeladen wird. Zweitens sollten Permission-Scopes überprüft werden (z. B. ob „contents: write“ wirklich nötig ist oder ob „read“ genügt), und ob der GITHUB_TOKEN-Umfang überhaupt verwendet wird. Drittens ist es ein guter Zeitpunkt, die Architektur so zu ändern, dass unkritische Validierungen auf „pull_request“ laufen und privilegierte Schritte erst nach Prüfung erfolgen. Als Vergleich zu anderen Plattformen gilt: Die Sicherheitsgewinne kommen am stärksten, wenn Berechtigungen an den Vertrauensgrad gekoppelt sind und nicht nur an die Event-Logik.
Der Ausblick ist klar: GitHub macht „pwn request“-Angriffe im Actions-Ökosystem schwerer und reduziert dadurch die Angriffsfläche für eine ganze Klasse von Supply-Chain-Compromises. Trotzdem bleibt die praktische Sicherheit für Unternehmen ein Zusammenspiel aus Tooling und Prozess: Zero-Trust-Prinzipien im CI, striktes Secrets-Handling, nachvollziehbare Freigaben und ein konsequentes Review-Verhalten bei Changes in Workflows. Entwickler sollten außerdem die Kompatibilität ihrer „actions/checkout“-Setups testen, weil die Rückportierung auf unterstützte Major-Versionen bis 16. Juli 2026 viele Nutzer erst später trifft. Wer die Standardhärtung nutzt und die wenigen Ausnahmen dokumentiert, verbessert die Robustheit der Pipeline messbar – ohne dabei die Produktivität vollständig auszubremsen.
💳 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 drosselt pwn-request-Angriffe mit actions/checkout in pull_request_target" 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 drosselt pwn-request-Angriffe mit actions/checkout in pull_request_target" 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 drosselt pwn-request-Angriffe mit actions/checkout in pull_request_target« bei Google Deutschland suchen, bei Bing oder Google News!