![\"Weaponizing](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05195516\/Weaponizing-AI-863-x-300.png\")
<\/p>\n<\/p>\n
Vorf\u00e4lle in j\u00fcngster Zeit haben bewiesen, dass Continuous-Integration-(CI)-Workflows das neue Angriffsfeld auf die Software\u2011Lieferkette sind. Sicherheitsfallen in GitHub-Actions-Workflows \u2013 etwa die unbereinigte Nutzung von Pull-Request-(PR)-Daten \u2013 k\u00f6nnen es Angreifern erm\u00f6glichen, w\u00e4hrend CI-Runs b\u00f6sartigen Code auszuf\u00fchren \u2013 mit verheerenden Folgen.<\/p>\n
So wurde der aufsehenerregende \u201eS1ngularity\u201c-Angriff auf das Nx\u2011Projekt<\/a>, der im August 2025 zum Diebstahl\u00a0 von 83.000 Secrets f\u00fchrte, genau auf diesen Fehlertyp zur\u00fcckgef\u00fchrt: ein Workflow, der Code-Injection \u00fcber einen unbereinigten PR\u2011Titel erlaubte, kombiniert mit den weitreichenden Rechten des pull_request_target\u2011Triggers. Dadurch konnten Angreifer npm\u2011Publishing\u2011Tokens aus dem Workflow stehlen und trojanisierte Pakete ver\u00f6ffentlichen. Ein darauffolgender Angriff mit dem \u201eShai\u2011Hulud\u201c-Wurm<\/a>, missbrauchte in \u00e4hnlicher Weise CI\u2011Pipelines, um Secrets aus Hunderten von Repositories zu exfiltrieren, und l\u00f6ste in einigen Varianten sogar einen \u201eDead Man\u2019s Switch<\/a>\u201c-Wiper aus. Diese F\u00e4lle unterstreichen das enorme Risiko: Wenn ein Angreifer Code in der CI eines Projekts mit Write\u2011Access\u2011Tokens ausf\u00fchren kann, kann er die gesamte Lieferkette kompromittieren.<\/b><\/p>\n Die Herausforderung besteht nicht darin, das Risiko zu verstehen, sondern diese Workflow\u2011Fehler in gro\u00dfem Ma\u00dfstab zu finden, bevor sie ausgenutzt werden. Deshalb hat JFrog RepoHunter<\/b> entwickelt \u2013 einen KI\u2011gest\u00fctzten Security\u2011Research\u2011Bot, der CI\/CD\u2011Exploitation\u2011Muster (\u201ePwn Requests\u201c) im Open\u2011Source\u2011Umfeld proaktiv erkennt, lange bevor daraus die n\u00e4chste Shai\u2011Hulud\u2011artige Kampagne wird.<\/p>\n In den vergangenen drei Monaten hat JFrog RepoHunter eingesetzt, um CI\/CD\u2011Schwachstellen proaktiv zu identifizieren und Maintainer in Open\u2011Source\u2011Repositories verantwortungsvoll zu informieren. K\u00fcrzlich starteten Angreifer mit dem Bot hackerbot-claw<\/b> eine b\u00f6sartige Kampagne und \u00fcbernahmen sieben Repositories<\/a> von Microsoft, DataDog, der CNCF und popul\u00e4ren Open\u2011Source\u2011Projekten wie Trivy. Der Angriff nutzte \u00e4hnliche KI\u2011gest\u00fctzte Techniken wie RepoHunter und zeigt, wie dieselbe Technologie von Angreifern gegen die Open\u2011Source\u2011Lieferkette eingesetzt werden kann.<\/p>\n In diesem Beitrag stellen wir 13 F\u00e4lle vor, die Maintainer nach JFrogs verantwortungsvoller Offenlegung behoben haben. Sie zeigen echte \u201ePwn\u2011Request\u201c-Szenarien, in denen nicht vertrauensw\u00fcrdige PR\u2011Metadaten, Branch\u2011Namen oder von Angreifern kontrollierte Skripte zur Ausf\u00fchrung von Remote Code in GitHub\u2011CI\u2011Pipelines f\u00fchren. Die Auswirkungen gehen \u00fcber Code\u2011Repositories hinaus und bedrohen globale Finanzsysteme, kritische KI\u2011Infrastruktur, mobile und eingebettete Ger\u00e4te, wissenschaftliche Publikationsplattformen, JavaScript\u2011Sprachstandards sowie Netzwerkinfrastruktur, auf die Milliarden von Nutzern weltweit angewiesen sind.<\/p>\n JFrog plant, einen umfangreichen Folgeartikel zu ver\u00f6ffentlichen, der erl\u00e4utert, wie RepoHunter gebaut ist und wie die Ergebnisse validiert werden, sobald die Behebung der Probleme in en betroffenen Projekten abgeschlossen ist.<\/p>\n J\u00fcngste Vorf\u00e4lle haben bewiesen, dass Continuous-Integration-(CI)<\/a>-Workflows das neue Schlachtfeld f\u00fcr Angriffe auf die Software\u2011Lieferketten sind. <\/b>Fallstricke in GitHub-Actions-Workflows \u2013 wie die unbereinigte Nutzung von Pull-Request-(PR)-Daten \u2013 k\u00f6nnen es Angreifern erm\u00f6glichen, w\u00e4hrend CI-Runs b\u00f6sartigen Code auszuf\u00fchren \u2013 mit verheerenden Folgen.<\/p>\n Die \u201eShai Hulud\u201c-Angriffe<\/a> markierten einen Wendepunkt f\u00fcr das JavaScript\u2011\u00d6kosystem. Durch die \u00dcbernahme langlebiger, statischer npm\u2011Tokens produktiver Maintainer konnten Angreifer b\u00f6sartige Payloads in weit verbreitete Pakete einschleusen und das npm\u2011Registry de facto in einen Distributionskanal f\u00fcr Malware verwandeln.<\/p>\n Die meisten npm\u2011Entwickler verlassen sich weiterhin auf statische npm\u2011Tokens, die in GitHub\u2011Actions\u2011Secrets oder lokalen Umgebungsvariablen gespeichert werden. Das f\u00fchrt zu zwei zentralen Schwachstellen:<\/p>\n Als Reaktion auf die Shai\u2011Hulud\u2011Folgen hat npm Trusted Publishing eingef\u00fchrt<\/a>. Dieses Modell verabschiedet sich von statischen, langlebigen Secrets zugunsten kurzlebiger, identit\u00e4tsbasierter Authentifizierung.<\/p>\n Statt ein Passwort oder Token zu speichern, definieren Sie eine Vertrauensbeziehung zwischen npm und Ihrem CI\/CD\u2011Provider (z.\u202fB. GitHub Actions).<\/p>\n Mit Trusted Publishing gibt es kein statisches Secret mehr, das Angreifer stehlen k\u00f6nnen, und die Vertrauensbasis wurde auf CI\/CD verlagert.<\/p>\n Das wirft die Frage auf: Ist CI\/CD eine unfehlbare Vertrauensbasis?<\/strong><\/p>\n Ein \u201ePwn Request\u201c, also eine CI\u2011\u00dcbernahme via Pull Request, ist eine Klasse von Schwachstellen, bei der:<\/p>\n Der Begriff \u201ePwn Request\u201c wurde durch die GitHub\u2011Security\u2011Lab\u2011Guidance von 2021 popularisiert: \u201ePreventing pwn requests<\/a>\u201c. Die Idee: Ein scheinbar \u201enormaler\u201c Pull Request kann das CI\u2011System eines Repositories \u201epwnen\u201c und damit oft auch das Repo \u2013 und nicht selten die gesamte Organisation.<\/p>\n RepoHunter ist ein KI\u2011gest\u00fctzter Security\u2011Research\u2011Bot von JFrog, der die RIsiken f\u00fcr CI\/CD\u2011\u00dcbernahme\u00a0 in Open\u2011Source\u2011\u00d6kosystemen proaktiv identifiziert.<\/p>\n Das Ziel ist klar: Workflow-Fehlkonfigurationen erkennen, die es nicht vertrauensw\u00fcrdigen Contributors erlauben, Code in privilegierten CI\u2011Kontexten auszuf\u00fchren \u2013 bevor Angreifer diese operationalisieren k\u00f6nnen.<\/b><\/p>\n In einer aktuellen Forschungsserie identifizierte RepoHunter mehrere CI\/CD\u2011Takeover\u2011Schwachstellen in weit verbreiteten Open\u2011Source\u2011Projekten \u2013 darunter Automatisierungsplattformen f\u00fcr Unternehmen, Programmiersprachen\u2011Toolchains, Entwickler-Infrastruktur und KI\u2011Frameworks.<\/p>\n RepoHunter automatisiert die Schwachstellen\u2011Detektion mit einer praxisorientierten Defense\u2011Pipeline:<\/p>\n Um zu verstehen, was verhindert wurde, ist es wichtig, die gesamte Angriffskette zu kennen, die RepoHunter erkennen soll.<\/p>\n Ein CI\u2011Supply\u2011Chain\u2011Angriff verl\u00e4uft in vier Phasen:<\/p>\n \u00dcbergreifend \u00fcber Repositories haben wir ein gef\u00e4hrliches Muster wiederholt beobachtet: Workflows, die durch angreifergesteuerte Events getriggert werden, angreiferseitigen Input verwenden und mit Repository\u2011weiten Privilegien laufen.<\/p>\n Der h\u00e4ufigste und gef\u00e4hrlichste Trigger war Das bedeutet: Das erm\u00f6glicht Maintainern, privilegierte Automatisierung als Reaktion auf Pull Requests auszuf\u00fchren; Fehlkonfigurationen erlauben es jedoch nicht vertrauensw\u00fcrdigen Contributors, diese privilegierte Ausf\u00fchrung zu beeinflussen.<\/p>\n Ein weiterer verbreiteter Irrtum betrifft Approval\u2011Einstellungen. Viele Maintainer aktivieren \u201eRequire approval for external contributors\u201c und glauben, dadurch gesch\u00fctzt zu sein. Zwar gilt das f\u00fcr Die Automatisierung von RepoHunter erkennt Muster \u00fcber all diese Trigger hinweg und erm\u00f6glicht es, Schwachstellen anzumerken, bevor sie ausgenutzt werden. Details zu konkreten Schwachstellen in Weitere strukturelle Aspekte versch\u00e4rfen das Risiko:<\/p>\n Diese Fehlkonfigurationen bilden die exponierte Schicht. Ist sie vorhanden, wird die Ausnutzung einfach.<\/p>\n \u00dcber alle von RepoHunter identifizierten Schwachstellen hinweg folgte die Ausnutzung drei konsistenten Mustern. Jedes dieser Muster wird in dedizierten technischen Writeups unten ausf\u00fchrlich behandelt \u2013 inklusive vollst\u00e4ndiger PoCs der gefundenen Schwachstellen.<\/p>\n Der Workflow checkt den PR\u2011Head aus und f\u00fchrt Test\u2011Code oder Skripte aus, die der Angreifer kontrolliert \u2013 als Teil des Test\u2011CI\u2011Prozesses.<\/p>\n Der Workflow checkt den PR\u2011Head aus und f\u00fchrt Build\u2011Skripte aus, die der Angreifer kontrolliert (npm, make, Gradle, cargo, Python usw.) \u2013 als Teil des Build\u2011CI\u2011Prozesses.<\/p>\n Ohne korrektes Escaping\/Sanitizing kann ein b\u00f6sartiger Branch\u2011Name oder eine vom Angreifer kontrollierte Config\u2011Datei beliebige Command\u2011Injection ausl\u00f6sen \u2013 im Workflow\u2011Skript oder in anderen Tools.<\/p>\n Sobald ein Angreifer Remote Code Execution in einem privilegierten CI\u2011Workflow erreicht, folgt das Credential\u2011Harvesting.<\/p>\n In der Praxis bedeutet das die systematische Suche nach Secrets in der Umgebung:<\/p>\n In Umgebungen mit self\u2011hosted Runners steigt das Risiko zus\u00e4tzlich. RCE kann dort Instanzrollen, Managed Identities oder Netzwerkzugriff auf interne Systeme erben.<\/p>\n An diesem Punkt hat der Angreifer alles N\u00f6tige, um \u00fcber ein einzelnes Repository hinauszugehen.<\/p>\n Credential\u2011Wiederverwendung ist der Multiplikator.<\/p>\n Cloud\u2011Credentials erm\u00f6glichen Manipulation von Storage, Austausch von Artifacts und weitergehenden Infrastrukturzugriff.<\/p>\n Ein einziger unsicherer Workflow kann daher ausufern zu:<\/p>\n So propagiert ein Lieferketten\u2011Wurm; Automatisierung macht aus Fehlkonfigurationen ein systemisches Risiko.<\/p>\nWarum CI\/CD das neue Ziel ist<\/h2>\n
Problem: die Fragilit\u00e4t von Secrets<\/h3>\n
\n
NPM-L\u00f6sung: Trusted Publishing<\/h3>\n
![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200141\/JFrogs-AI-Research-Bot-image10.png\")
<\/p>\nWas ist ein \u201ePwn Request\u201c\/GitHub-Actions-CI\u2011Takeover?<\/h2>\n
\n
GITHUB_TOKEN<\/code>);<\/li>\n![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200115\/JFrogs-AI-Research-Bot-image5.png\")
<\/p>\nRepoHunter: CI\u2011\u00dcbernahmen aufsp\u00fcren, bevor sie skalieren<\/h2>\n
Innovation absichern \u2013 mit innovativer Security<\/h3>\n
![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200136\/JFrogs-AI-Research-Bot-image9.png\")
RepoHunter\u2011Dashboard mit Beispielen von Befunden<\/i><\/p>\nWie arbeitet RepoHunter?<\/h3>\n
\n
![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200148\/JFrogs-AI-Research-Bot-image11.png\")
<\/p>\nVier Phasen eines CI\u2011Supply\u2011Chain\u2011Angriffs<\/h2>\n
\n
Phase Eins: Exposure<\/h3>\n
Wie CI\u2011Fehlkonfigurationen zu Einstiegspunkten in die Lieferkette werden<\/h4>\n
pull_request_target<\/code>. Auf den ersten Blick \u00e4hnelt pull_request_target<\/code> dem Trigger pull_request<\/code>. Der Unterschied ist subtil, aber kritisch.<\/p>\n\n
pull_request<\/code> l\u00e4uft im Kontext des Forks, der die \u00c4nderung eingereicht hat.<\/li>\npull_request_target<\/code> l\u00e4uft im Kontext des Basis\u2011Repositories.<\/li>\n<\/ul>\npull_request_target<\/code>-Workflows erben:<\/p>\n\n
pull_request<\/code>, verhindert aber keine sofortige Ausf\u00fchrung bei:<\/p>\n\n
pull_request_target<\/code><\/li>\nissue_comment<\/code><\/li>\nworkflow_run<\/code><\/li>\n<\/ul>\n![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200100\/JFrogs-AI-Research-Bot-image3-1024x270.png\")
\nGithub Workflow Approval Documentation<\/span><\/i><\/a><\/p>\nissue_comment<\/code> und workflow_run<\/code> folgen in k\u00fcnftigen Blogartikeln.<\/p>\n\n
\nWorkflows ohne explizite Blockierung von Berechtigungen erben Repository\u2011Defaults. Viele Repos haben historisch \u201eRead and write\u201c als Default gesetzt \u2013 damit erh\u00e4lt jeder Workflow implizit Schreibzugriff.<\/li>\n
\nStandardm\u00e4\u00dfig nutzt actions\/checkout persist-credentials: true und schreibt das aktive GITHUB_TOKEN<\/code> in .git\/config<\/code>. Das ist ein bekanntes Issue<\/a> der GitHub\u2011Checkout\u2011Action; ein Angreifer mit Code\u2011Ausf\u00fchrung kann dieses Token au\u00dferhalb des Job\u2011Kontexts (solange der Job aktiv ist) extrahieren und wiederverwenden \u2013 oft ohne Wissen der Maintainer.<\/li>\n
\nWenig sichtbare Repositories mit Labels wie \u201etest\u201c, \u201esandbox\u201c oder \u201eexperimental\u201c speichern h\u00e4ufig Organisation\u2011Secrets, Publishing\u2011Rechte f\u00fcr Pakete oder Cloud\u2011Credentials. Die Kompromittierung eines solchen Repos kann die gesamte Organisation kompromittieren.<\/li>\n<\/ul>\nPhase Zwei: Ausf\u00fchrung<\/h3>\n
Drei wiederkehrende Muster in der CI-Exploitation<\/h4>\n
\n
\n
\n
Phase Drei: Harvesting<\/h3>\n
Was Angreifer nach der CI\u2011Kompromittierung extrahieren<\/h4>\n
\n
GITHUB_TOKEN<\/code>. Falls es Schreib- oder weitergehende Berechtigungen hat, kann es zur Repository\u2011\u00dcbernahme und Workflow\u2011Modifikation genutzt werden.<\/li>\nPhase Vier: Propagation<\/h3>\n
Von der Repository\u2011Kompromittierung zu den Auswirkungen auf das \u00d6kosystem<\/h4>\n
\n
\n
RepoHunter CI\\CD Takeover Zusammenfassung<\/h2>\n
![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200121\/JFrogs-AI-Research-Bot-image6.png\")
<\/p>\n![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200127\/JFrogs-AI-Research-Bot-image7.png\")
Ansible\u2011Referenzen in Open\u2011Source\u2011Code<\/em><\/p>\n![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200050\/JFrogs-AI-Research-Bot-image1.png\")
Verwundbarer Ansible\u2011Workflow mit ![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200056\/JFrogs-AI-Research-Bot-image2.png\")
GITHUB_TOKEN mit Zugriff auf Ansible\u2011Pakete konfiguriert.![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200131\/JFrogs-AI-Research-Bot-image8.png\")
Packages\u2011Seite der Ansible\u2011Organisation mit 29 Paketen und Millionen Downloads<\/em><\/p>\n![\"JFrog\u2019s](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2026\/03\/05200153\/JFrogs-AI-Research-Bot-image12.png\")
Identifying a vulnerable GitHub workflow in the JFrog Platform<\/em><\/p>\n