Wie der JFrog AI-Research-Bot Open-Source-Software-CI/CD-Schwachstellen fand und Shai Hulud 3.0 verhinderte.

Vorfälle in jüngster Zeit haben bewiesen, dass Continuous-Integration-(CI)-Workflows das neue Angriffsfeld auf die Software‑Lieferkette sind. Sicherheitsfallen in GitHub-Actions-Workflows – etwa die unbereinigte Nutzung von Pull-Request-(PR)-Daten – können es Angreifern ermöglichen, während CI-Runs bösartigen Code auszuführen – mit verheerenden Folgen.

So wurde der aufsehenerregende „S1ngularity“-Angriff auf das Nx‑Projekt, der im August 2025 zum Diebstahl  von 83.000 Secrets führte, genau auf diesen Fehlertyp zurückgeführt: ein Workflow, der Code-Injection über einen unbereinigten PR‑Titel erlaubte, kombiniert mit den weitreichenden Rechten des pull_request_target‑Triggers. Dadurch konnten Angreifer npm‑Publishing‑Tokens aus dem Workflow stehlen und trojanisierte Pakete veröffentlichen. Ein darauffolgender Angriff mit dem „Shai‑Hulud“-Wurm, missbrauchte in ähnlicher Weise CI‑Pipelines, um Secrets aus Hunderten von Repositories zu exfiltrieren, und löste in einigen Varianten sogar einen „Dead Man’s Switch“-Wiper aus. Diese Fälle unterstreichen das enorme Risiko: Wenn ein Angreifer Code in der CI eines Projekts mit Write‑Access‑Tokens ausführen kann, kann er die gesamte Lieferkette kompromittieren.

Die Herausforderung besteht nicht darin, das Risiko zu verstehen, sondern diese Workflow‑Fehler in großem Maßstab zu finden, bevor sie ausgenutzt werden. Deshalb hat JFrog RepoHunter entwickelt – einen KI‑gestützten Security‑Research‑Bot, der CI/CD‑Exploitation‑Muster („Pwn Requests“) im Open‑Source‑Umfeld proaktiv erkennt, lange bevor daraus die nächste Shai‑Hulud‑artige Kampagne wird.

In den vergangenen drei Monaten hat JFrog RepoHunter eingesetzt, um CI/CD‑Schwachstellen proaktiv zu identifizieren und Maintainer in Open‑Source‑Repositories verantwortungsvoll zu informieren. Kürzlich starteten Angreifer mit dem Bot hackerbot-claw eine bösartige Kampagne und übernahmen sieben Repositories von Microsoft, DataDog, der CNCF und populären Open‑Source‑Projekten wie Trivy. Der Angriff nutzte ähnliche KI‑gestützte Techniken wie RepoHunter und zeigt, wie dieselbe Technologie von Angreifern gegen die Open‑Source‑Lieferkette eingesetzt werden kann.

In diesem Beitrag stellen wir 13 Fälle vor, die Maintainer nach JFrogs verantwortungsvoller Offenlegung behoben haben. Sie zeigen echte „Pwn‑Request“-Szenarien, in denen nicht vertrauenswürdige PR‑Metadaten, Branch‑Namen oder von Angreifern kontrollierte Skripte zur Ausführung von Remote Code in GitHub‑CI‑Pipelines führen. Die Auswirkungen gehen über Code‑Repositories hinaus und bedrohen globale Finanzsysteme, kritische KI‑Infrastruktur, mobile und eingebettete Geräte, wissenschaftliche Publikationsplattformen, JavaScript‑Sprachstandards sowie Netzwerkinfrastruktur, auf die Milliarden von Nutzern weltweit angewiesen sind.

JFrog plant, einen umfangreichen Folgeartikel zu veröffentlichen, der erläutert, wie RepoHunter gebaut ist und wie die Ergebnisse validiert werden, sobald die Behebung der Probleme in en betroffenen Projekten abgeschlossen ist.

Warum CI/CD das neue Ziel ist

Jüngste Vorfälle haben bewiesen, dass Continuous-Integration-(CI)-Workflows das neue Schlachtfeld für Angriffe auf die Software‑Lieferketten sind. Fallstricke in GitHub-Actions-Workflows – wie die unbereinigte Nutzung von Pull-Request-(PR)-Daten – können es Angreifern ermöglichen, während CI-Runs bösartigen Code auszuführen – mit verheerenden Folgen.

Die „Shai Hulud“-Angriffe markierten einen Wendepunkt für das JavaScript‑Ökosystem. Durch die Übernahme langlebiger, statischer npm‑Tokens produktiver Maintainer konnten Angreifer bösartige Payloads in weit verbreitete Pakete einschleusen und das npm‑Registry de facto in einen Distributionskanal für Malware verwandeln.

Problem: die Fragilität von Secrets

Die meisten npm‑Entwickler verlassen sich weiterhin auf statische npm‑Tokens, die in GitHub‑Actions‑Secrets oder lokalen Umgebungsvariablen gespeichert werden. Das führt zu zwei zentralen Schwachstellen:

• Persistenz: Wenn ein Token geleakt wird, bleibt es unbegrenzt gültig (oder bis zum manuellen Widerruf) – eine dauerhafte Hintertür für Angreifer.
• Umfang: Diese Tokens haben oft keine granularen Berechtigungen. Ein kompromittiertes Secret kann so ein ganzes Portfolio an Paketen gefährden.

NPM-Lösung: Trusted Publishing

Als Reaktion auf die Shai‑Hulud‑Folgen hat npm Trusted Publishing eingeführt. Dieses Modell verabschiedet sich von statischen, langlebigen Secrets zugunsten kurzlebiger, identitätsbasierter Authentifizierung.

Statt ein Passwort oder Token zu speichern, definieren Sie eine Vertrauensbeziehung zwischen npm und Ihrem CI/CD‑Provider (z. B. GitHub Actions).

Mit Trusted Publishing gibt es kein statisches Secret mehr, das Angreifer stehlen können, und die Vertrauensbasis wurde auf CI/CD verlagert.

Das wirft die Frage auf: Ist CI/CD eine unfehlbare Vertrauensbasis?

Was ist ein „Pwn Request“/GitHub-Actions-CI‑Takeover?

Ein „Pwn Request“, also eine CI‑Übernahme via Pull Request, ist eine Klasse von Schwachstellen, bei der:

1. ein Angreifer einen Pull Request öffnet (oder per Kommentar/Label einen Workflow triggert) – aus einem Fork oder Branch, den er kontrolliert;
2. der GitHub‑Actions‑Workflow des Projekts in einem privilegierten Kontext läuft (z. B. Berechtigungen des Basis‑Repositories, Zugriff auf Secrets, hoch privilegiertes GITHUB_TOKEN);
3. angreifergesteuerter Input in diesem Kontext ausgeführt wird (z. B. PR‑Branch‑Code, PR‑Titel/‑Body, Branch‑Name oder Konfiguration, die Shell‑Befehle ausführt);
4. der Runner den Code des Angreifers mit denselben Rechten und Secrets wie der Workflow ausführt, was zu Remote Code Execution (RCE) in der CI führt;
5. und Angreifer anschließend Tokens und Secrets exfiltrieren, Code pushen, Workflows ändern, Pakete veröffentlichen oder sich lateral in der Organisation bewegen können.

Der Begriff „Pwn Request“ wurde durch die GitHub‑Security‑Lab‑Guidance von 2021 popularisiert: „Preventing pwn requests“. Die Idee: Ein scheinbar „normaler“ Pull Request kann das CI‑System eines Repositories „pwnen“ und damit oft auch das Repo – und nicht selten die gesamte Organisation.

RepoHunter: CI‑Übernahmen aufspüren, bevor sie skalieren

Innovation absichern – mit innovativer Security

RepoHunter ist ein KI‑gestützter Security‑Research‑Bot von JFrog, der die RIsiken für CI/CD‑Übernahme  in Open‑Source‑Ökosystemen proaktiv identifiziert.

Das Ziel ist klar: Workflow-Fehlkonfigurationen erkennen, die es nicht vertrauenswürdigen Contributors erlauben, Code in privilegierten CI‑Kontexten auszuführen – bevor Angreifer diese operationalisieren können.

In einer aktuellen Forschungsserie identifizierte RepoHunter mehrere CI/CD‑Takeover‑Schwachstellen in weit verbreiteten Open‑Source‑Projekten – darunter Automatisierungsplattformen für Unternehmen, Programmiersprachen‑Toolchains, Entwickler-Infrastruktur und KI‑Frameworks.

RepoHunter‑Dashboard mit Beispielen von Befunden

Wie arbeitet RepoHunter?

RepoHunter automatisiert die Schwachstellen‑Detektion mit einer praxisorientierten Defense‑Pipeline:

1. Erfassung: Public Repositories und deren CI/CD‑Konfigurationen crawlen, um die exponierte Angriffsfläche zu verstehen.
2. Identifizierung: Verwundbare Workflow‑Muster erkennen, in denen nicht vertrauenswürdiger Input auf erhöhte Berechtigungen oder Secret‑Zugriff trifft.
3. Validierung: Ausnutzbarkeit mit KI validieren und realistische Exploitation‑Szenarien für die manuelle Ausführung generieren.
4. Offenlegung: Detaillierte Schwachstellen‑Reports mit Evidenz und konkreten Hinweisen zur Behebung erstellen.

Um zu verstehen, was verhindert wurde, ist es wichtig, die gesamte Angriffskette zu kennen, die RepoHunter erkennen soll.

Vier Phasen eines CI‑Supply‑Chain‑Angriffs

Ein CI‑Supply‑Chain‑Angriff verläuft in vier Phasen:

1. Exposure: Fehlkonfigurationen im Workflow schaffen ein Takeover‑Primitive.
2. Ausführung: Durch vom Angreifer kontrollierte Eingaben wird die Ausführung von Code in CI erreicht.
3. Harvesting: Credentials werden aus der Workflow‑Umgebung extrahiert.
4. Propagation: Gestohlene Credentials werden genutzt, um Repositories, Registries und Infrastruktur zu kompromittieren.

Phase Eins: Exposure

Wie CI‑Fehlkonfigurationen zu Einstiegspunkten in die Lieferkette werden

Übergreifend über Repositories haben wir ein gefährliches Muster wiederholt beobachtet: Workflows, die durch angreifergesteuerte Events getriggert werden, angreiferseitigen Input verwenden und mit Repository‑weiten Privilegien laufen.

Der häufigste und gefährlichste Trigger war pull_request_target. Auf den ersten Blick ähnelt pull_request_target dem Trigger pull_request. Der Unterschied ist subtil, aber kritisch.

• pull_request läuft im Kontext des Forks, der die Änderung eingereicht hat.
• pull_request_target läuft im Kontext des Basis‑Repositories.

Das bedeutet: pull_request_target-Workflows erben:

• Repository‑Secrets
• Repository‑weite GITHUB_TOKEN-Berechtigungen
• Schreibzugriff, falls konfiguriert

Das ermöglicht Maintainern, privilegierte Automatisierung als Reaktion auf Pull Requests auszuführen; Fehlkonfigurationen erlauben es jedoch nicht vertrauenswürdigen Contributors, diese privilegierte Ausführung zu beeinflussen.

Ein weiterer verbreiteter Irrtum betrifft Approval‑Einstellungen. Viele Maintainer aktivieren „Require approval for external contributors“ und glauben, dadurch geschützt zu sein. Zwar gilt das für pull_request, verhindert aber keine sofortige Ausführung bei:

• pull_request_target
• issue_comment
• workflow_run

Github Workflow Approval Documentation

Die Automatisierung von RepoHunter erkennt Muster über all diese Trigger hinweg und ermöglicht es, Schwachstellen anzumerken, bevor sie ausgenutzt werden. Details zu konkreten Schwachstellen in issue_comment und workflow_run folgen in künftigen Blogartikeln.

Weitere strukturelle Aspekte verschärfen das Risiko:

• Berechtigungsvererbung
  Workflows ohne explizite Blockierung von Berechtigungen erben Repository‑Defaults. Viele Repos haben historisch „Read and write“ als Default gesetzt – damit erhält jeder Workflow implizit Schreibzugriff.
• Credential‑Persistenz
  Standardmäßig nutzt actions/checkout persist-credentials: true und schreibt das aktive GITHUB_TOKEN in .git/config. Das ist ein bekanntes Issue der GitHub‑Checkout‑Action; ein Angreifer mit Code‑Ausführung kann dieses Token außerhalb des Job‑Kontexts (solange der Job aktiv ist) extrahieren und wiederverwenden – oft ohne Wissen der Maintainer.
• „Test‑Repository“-Falle
  Wenig sichtbare Repositories mit Labels wie „test“, „sandbox“ oder „experimental“ speichern häufig Organisation‑Secrets, Publishing‑Rechte für Pakete oder Cloud‑Credentials. Die Kompromittierung eines solchen Repos kann die gesamte Organisation kompromittieren.

Diese Fehlkonfigurationen bilden die exponierte Schicht. Ist sie vorhanden, wird die Ausnutzung einfach.

Phase Zwei: Ausführung

Drei wiederkehrende Muster in der CI-Exploitation

Über alle von RepoHunter identifizierten Schwachstellen hinweg folgte die Ausnutzung drei konsistenten Mustern. Jedes dieser Muster wird in dedizierten technischen Writeups unten ausführlich behandelt – inklusive vollständiger PoCs der gefundenen Schwachstellen.

1. Test‑basierte Ausführung

Der Workflow checkt den PR‑Head aus und führt Test‑Code oder Skripte aus, die der Angreifer kontrolliert – als Teil des Test‑CI‑Prozesses.

2. Build‑Skripts und Installer‑basierte Ausführung

Der Workflow checkt den PR‑Head aus und führt Build‑Skripte aus, die der Angreifer kontrolliert (npm, make, Gradle, cargo, Python usw.) – als Teil des Build‑CI‑Prozesses.

3. Branch‑ und Config‑Injection

Ohne korrektes Escaping/Sanitizing kann ein bösartiger Branch‑Name oder eine vom Angreifer kontrollierte Config‑Datei beliebige Command‑Injection auslösen – im Workflow‑Skript oder in anderen Tools.

Phase Drei: Harvesting

Was Angreifer nach der CI‑Kompromittierung extrahieren

Sobald ein Angreifer Remote Code Execution in einem privilegierten CI‑Workflow erreicht, folgt das Credential‑Harvesting.

In der Praxis bedeutet das die systematische Suche nach Secrets in der Umgebung:

• Erstes Ziel ist das GITHUB_TOKEN. Falls es Schreib- oder weitergehende Berechtigungen hat, kann es zur Repository‑Übernahme und Workflow‑Modifikation genutzt werden.
• Personal Access Tokens und private Schlüssel von GitHub Apps sind noch mächtiger. Sie gewähren oft organisationsweiten Zugriff und erlauben laterale Bewegung.
• Tokens zum Paket‑Publishing sind ein weiteres wertvolles Ziel. npm‑Tokens, PyPI‑Tokens, Cargo‑Registry‑Tokens und Docker‑Hub‑Credentials erlauben die Veröffentlichung trojanisierter Versionen weit verbreiteter Komponenten.
• Cloud‑Credentials liegen oft als Repository‑ oder Organisations‑Secrets vor. AWS‑Access‑Keys, GCP‑Service‑Account‑Keys, Azure‑Service‑Principals oder OIDC‑basierte Identity‑Federation‑Berechtigungen können eine CI‑Kompromittierung in eine Cloud‑Infrastruktur‑Kompromittierung verwandeln.

In Umgebungen mit self‑hosted Runners steigt das Risiko zusätzlich. RCE kann dort Instanzrollen, Managed Identities oder Netzwerkzugriff auf interne Systeme erben.

An diesem Punkt hat der Angreifer alles Nötige, um über ein einzelnes Repository hinauszugehen.

Phase Vier: Propagation

Von der Repository‑Kompromittierung zu den Auswirkungen auf das Ökosystem

Credential‑Wiederverwendung ist der Multiplikator.

• Mit Schreibzugriff auf Repositories können Angreifer bösartige Workflows injizieren, um Persistenz herzustellen.
• Mit Paket‑Publishing‑Tokens können sie trojanisierte Versionen vertrauenswürdiger Komponenten veröffentlichen.
• Mit Container‑Registry‑Credentials können sie Images ersetzen, die in Production‑Deployments genutzt werden.

Cloud‑Credentials ermöglichen Manipulation von Storage, Austausch von Artifacts und weitergehenden Infrastrukturzugriff.

Ein einziger unsicherer Workflow kann daher ausufern zu:

• organisationsweiter Repository‑Kompromittierung
• Registry‑weiter Paket‑Kompromittierung
• Infektion von Developer‑Umgebungen
• Manipulation der Cloud‑Infrastruktur
• Downstream‑CI‑Kompromittierung

So propagiert ein Lieferketten‑Wurm; Automatisierung macht aus Fehlkonfigurationen ein systemisches Risiko.

RepoHunter CI\CD Takeover Zusammenfassung

Projekt	Schwachstelle & Schweregrad	Auswirkung auf die Supply Chain
Ansible Enterprise‑IT‑Automationsplattform, die sowohl von Fortune‑500‑Unternehmen als auch von Open‑Source‑Maintainers genutzt wird.	GHSA-fwqj-x86q-prmq Kritisch	Die Kompromittierung von Ansible‑Plattform‑Paketen oder ‑Modulen könnte es Angreifern erlauben, bösartige Automationsskripte einzuschleusen – mit Auswirkungen auf das Konfigurationsmanagement und Deployment‑Pipelines in Tausenden von Unternehmen weltweit.
P4 language Programmiersprache für Netzwerkswitches. Weit verbreitet in SDN‑, Datacenter‑ und Networking‑Device‑Toolchains.	GHSA-6cw7-hxfh-8×94 Kritisch	Bösartige Änderungen könnten sich in SDN‑Umgebungen großer Unternehmen wie Google, AT&T und Intel. ausbreiten und es Angreifern ermöglichen, Netzwerktraffic zu manipulieren oder kritische Infrastruktur zu stören.
Petgraph Beliebte Rust‑Graph‑Library für Anwendungen in Algorithmen, Data Science und Networking.	Kritisch	Poisoned versions can affect hundreds of downstream Rust crates and applications, potentially exposing sensitive data, corrupting analytics pipelines, or introducing vulnerabilities in widely used systems.
QGIS Open‑Source‑Geoinformationssystem (GIS), genutzt von Regierungen, Kommunen und Forschungseinrichtungen.	CVE-2026-24480 Kritisch	Kompromittierte QGIS‑Releases könnten bösartige Skripte in GIS‑Workflows einschleusen – mit Auswirkungen auf kritisches Mapping, Stadtplanung oder Regierungsprojekte auf nationaler oder kommunaler Ebene.
Sdkman Weit verbreiteter Toolchain‑Manager für JVM‑SDKs.	GHSA-cprm-c872-3fw7 Kritisch	Eine Lieferketten‑Kompromittierung könnte bösartige SDKs oder Skripte verteilen – mit direkten Folgen für das Java‑Ökosystem und potenziellen Schwachstellen in Millionen von Enterprise‑ und Open‑Source‑Applikationen.
tc39/proposal-amount Repository für JavaScript‑Standardisierungsvorschläge.	GHSA-43vf-c68r-43mr Kritisch	Die Manipulation von Vorschlägen oder Tools könnte Schwachstellen im JavaScript-Ökosystem verursachen, die sich auf Milliarden von Websites und Anwendungen auswirken und zu unsicheren Sprachverhalten in der globalen Entwickler-Community führen könnten.
Telepresence CNCF‑Open‑Source‑Tool für Kubernetes‑Entwickler, das lokale Entwicklung in Remote‑Clustern ermöglicht.	GHSA-gc3r-m7gq-495f Kritisch	Eine Kompromittierung könnte bösartige Binaries oder Container‑Images verteilen, Cloud‑Native‑Entwicklungs‑Workflows beeinflussen und Risiken in Enterprise‑Kubernetes‑Umgebungen einführen.
Typst Offizielles Registry für die Typst‑Satzsprache.	GHSA-j5gp-pf74-5pj6 Kritisch	Kompromittierte Typst‑Pakete könnten sich in nachgelagerte Satz‑Projekte, akademische Workflows und Enterprise‑Dokumentenautomatisierung ausbreiten – mit Auswirkungen auf Integrität und Verfügbarkeit veröffentlichter Inhalte.
Xorbitsai Open‑Source‑Framework für AI‑Inference und Model‑Serving, häufig in LangChain‑Sandbox‑Umgebungen eingesetzt.	Kritisch	Bösartige PyPI‑Pakete oder Docker‑Images könnten KI‑Modelle, LangChain‑Applikationen oder KI‑Services für Unternehmen kompromittieren, sich in nachgelagerte Frameworks ausbreiten und KI‑gestützte Entscheidungen beeinflussen.
Eclipse-theia Eclipse‑Open‑Source‑Framework für cloudbasierte IDEs.	CVE-2026-1699 Kritisch	Eine Kompromittierung könnte bösartigen Code in Cloud‑ oder Desktop‑IDEs injizieren, Entwickler‑Umgebungen beeinträchtigen und Malware in Enterprise‑Projekte oder Open‑Source‑Repositories einschleusen.
Tencent Mobile‑ und Embedded‑AI‑Inference‑Framework.	GHSA-c44p-qr97-jccv Hoch	Ein Lieferketten‑Angriff könnte produktive KI‑Features in massenhaft eingesetzten Apps wie WeChat (1,4 Mrd.+ Nutzer) betreffen und Model‑Poisoning oder Data Leakage in Endnutzer‑Applikationen verursachen.
Ceph Verteilte Storage‑Plattform (Ceph).	GHSA-p433-fp4g-pc2c Hoch	Bösartige Änderungen könnten sich auf Cloud‑Provider, Enterprise‑Storage‑Deployments oder Downstream‑Distributionen ausbreiten – mit Risiken für Datenintegrität, Verfügbarkeit und den Schutz sensibler Informationen.
Parse-community Open‑Source‑Backend‑as‑a‑Service‑Server.	GHSA-6w8g-mgvv-3fcj Medium	Kompromittierte Parse‑Server‑Pakete könnten Backend‑Schwachstellen in zahlreiche Mobile‑ und Web‑Apps einschleusen, Datenmanipulation, Exfiltration sensibler Informationen oder Betriebsstörungen ermöglichen.

 

Dieser Blogartikel deckt insgesamt 13 Schwachstellen ab: 10 kritisch, 2 hoch und 1 mittel – in verschiedenen OSS‑Projekten. RepoHunter hat weitere Schwachstellen gefunden, die verantwortungsvoll gemeldet und in anderen GitHub‑Repos von Organisationen wie SAP und RedHat behoben wurden.

Hypothetisches Beispiel: Ein Shai‑Hulud‑artiger CI‑Wurm

Die in diesem Beitrag genannten Fälle wurden verantwortungsvoll gemeldet und in den meisten Fällen behoben. Die potenzielle „Katastrophe“ entsteht, wenn Angreifer dieselben Muster zuerst finden und automatisiert über Ökosysteme hinweg ausnutzen.

Realistischer Dominoeffekt im Stil von Shai‑Hulud – basierend auf den Mechanismen der Eskalation von Privilegien, die wir in mehreren Repositories demonstriert haben.

Wer betroffen ist (Contributors, Developers, Users)

• Maintainer: Triage‑Flut, Notfall‑Rotationen, Schlüssel‑Revokation und langfristiger Vertrauensaufbau.
• Contributors: Ihre PRs/Issues werden zur Ausführungsoberfläche (insbesondere mit issue_comment), und ihre Forks werden zur Bühne für Kompromittierungsnarrative.
• Entwickler ziehen kompromittierte Pakete, Container‑Images, CLIs oder Build‑Tools in lokale Dev‑ sowie CI‑Umgebungen.
• Endnutzer erleben Downstream‑Auswirkungen durch kompromittierte Anwendungen, Infrastrukturen oder Services, die auf kompromittierten Komponenten basieren.

Was wäre, wenn Angreifer die Schwachstellen vor der Aufdeckung durch RepoHunter ausgenutzt hätten?

Diese Schwachstellen wurden in Repositories entdeckt, die im Kern moderner Software‑Infrastruktur sitzen: Automatisierung in Firmen, Programmiersprachen‑Ökosysteme, Developer‑Toolchains, Paket‑Registries, AI‑Inference‑Frameworks und Repositories, die mit künftigen Sprachstandards verbunden sind.

Bei Ausnutzung könnten Angreifer bösartigen Code in vertrauenswürdige CI/CD‑Pipelines einschleusen, die Build‑Artifacts, Pakete, Container und Entwickler‑Tools über die globale Software‑Lieferkette verteilen.

Der Explosionsradius könnte Regierungssysteme, Großunternehmen, Open‑Source‑Projekte, akademische Forschungsumgebungen, Websites und Cloud‑Services umfassen. So betreiben etwa Enterprise‑Automatisierungsplattformen wie Ansible Infrastruktur quer durch alle Branchen, P4‑Compiler‑Ökosysteme befeuern programmierbare Netzwerke großer Tech‑Unternehmen, und Developer‑Tools wie SDKMAN oder Telepresence laufen direkt auf Millionen von Entwickler‑Maschinen und CI‑Runnern.

Die Kompromittierung von Distributions‑Hubs wie Typst‑Paketen oder weit verbreiteten Libraries wie petgraph könnte in Downstream‑Abhängigkeiten kaskadieren, die in Websites, SaaS‑Plattformen und Forschungstools genutzt werden. Selbst mit der JavaScript‑Standardisierung verbundene Repositories (TC39‑Proposals) befinden sich upstream von Technologien, die im gesamten Web verwendet werden.

Eine erfolgreiche CI‑Kompromittierung in diesen Upstream‑Projekten könnte daher bösartigen Code über gesamte Entwickler‑Ökosysteme und Produktionssysteme weltweit verbreiten – und ein Lieferketten‑Ereignis im Ausmaß von SolarWinds oder „Shai‑Hulud“ in moderner CI/CD‑Infrastruktur erzeugen.

Vulnerability Deep Dive: Ansible Platform

Schwachstelle: GHSA-fwqj-x86q-prmq

Schweregrad: Kritisch

Repository: ansible/ansible.platform

Vom Pull Request zur organisationsweiten Kompromittierung

Ansible ist eine der weltweit am weitesten verbreiteten Open‑Source‑Automationsplattformen.

Es wird von Unternehmen aller Größen und Branchen sowie von Open‑Source‑Repositories genutzt – für die Automatisierung der Bereitstellung von Infrastruktur, das Konfigurationsmanagement und die Bereitstellung von Applikationen.

Ansible‑Referenzen in Open‑Source‑Code

RepoHunter identifizierte im Repository ansible/ansible.platform einen Workflow, der pull_request_target nutzte, nicht vertrauenswürdigen Pull‑Request‑Code auscheckte und innerhalb der Trust‑Boundary des Basis‑Repositories ausführte.

Verwundbarer Ansible‑Workflow mit pull_request_target

Noch kritischer: Während der Ausführung wurden zwei sensible Tokens exponiert:

• AAP_GATEWAY_REPO_TOKEN – genutzt für bereichsübergreifenden Repository‑Zugriff und laterale Bewegung.
• GITHUB_TOKEN – konfiguriert mit vollem Zugriff auf die Pakete der Ansible‑Organisation.

GITHUB_TOKEN mit Zugriff auf Ansible‑Pakete konfiguriert.

Da actions/checkout Credentials standardmäßig persistiert, wurde das aktive GITHUB_TOKEN in die git‑Konfiguration des Runners geschrieben – eine Extraktion ist trivial, sobald Code‑Ausführung erreicht ist.

Von diesem Zeitpunkt an verlief die Eskalation zielstrebig.

Ein Angreifer könnte bösartige Pakete in der Ansible‑GitHub‑Organisation veröffentlichen, Workflows modifizieren, um Persistenz herzustellen, Build‑Artefakte fälschen oder Releases manipulieren, um eine laufende Kompromittierung zu verschleiern.

Das ist nicht theoretisch, sondern eine realistische Kompromittierung der Lieferkette auf Organisationsebene eines weltweit vertrauenswürdigen Automations‑Ökosystems.

Alle Ansible‑Nutzer, die Pakete von github.com/orgs/ansible/packages (derzeit Millionen Downloads) ziehen – sowie andere in der Ansible‑Organisation erkannte Secrets – waren gefährdet.

Packages‑Seite der Ansible‑Organisation mit 29 Paketen und Millionen Downloads

RepoHunter identifizierte die Schwachstelle, bevor sie in freier Wildbahn ausgenutzt wurde, und sie wurde über verantwortungsvolle Offenlegung behoben.

Was RepoHunter verhindert hat

Durch die Identifizierung dieser CI-Übernahme-Schwachstellen vor ihrer öffentlichen Ausnutzung verhinderte RepoHunter potenzielle Kompromittierungen in folgenden Bereichen:

• Automatisierungsökosysteme von Unternehmen
• Programmiersprachen‑Toolchains
• KI‑Inferenz‑Frameworks
• Entwicklerinfrastruktur
• Mit der Cloud verbundene Build-Systeme

Schützen Sie Ihre CI/CD mit JFrog Advanced Security

JFrog Advanced Security kann GitHub‑Workflow‑Dateien analysieren und CI/CD‑Schwachstellen erkennen – etwa einen pull_request_trigger in Kombination mit nicht vertrauenswürdiger Code‑Ausführung. Starten Sie eine kostenlose Testversion oder vereinbaren Sie noch heute eine Demo.

Identifying a vulnerable GitHub workflow in the JFrog Platform

Fazit – CI als kritische Infrastruktur absichern

CI ist nicht mehr nur ein Build-System. Es ist ein Identitätsbroker, eine Release-Autorität und ein Distributions-Gateway. Dadurch wird die Workflow-Konfiguration zu einer Sicherheitskontrolle und nicht zu einer praktischen Funktion.

Lesen Sie das Handbuch: Moderne CI/CD‑Automatisierung hat große Fortschritte gemacht. Diese Tools sind schnell und ermöglichen rasche Innovation – aber sie müssen sicher sein.

Sie müssen genau wissen, was Sie tun und warum. Jede Fehlkonfiguration kann eine katastrophale Kettenreaktion auslösen – und aus einem simplen Pull Request ein Einfallstor für eine organisationsweite Kompromittierung machen.

Organisationen müssen pull_request_target mit äußerster Vorsicht behandeln. Explizite Least‑Privilege‑Berechtigungen müssen in jedem Workflow definiert sein. Sämtliche nicht vertrauenswürdigen Inputs – etwa Metadaten oder Code – sind vor der Nutzung zu bereinigen. Die Persistenz von Credentials sollte deaktiviert werden, wenn sie nicht erforderlich ist. Privilegierte Automatisierung muss von nicht vertrauenswürdigen Ausführungen getrennt werden. Vor allem muss CI kontinuierlich überprüft werden. Eine manuelle Überprüfung reicht auf Ökosystemebene nicht aus.

Wir haben RepoHunter entwickelt, weil sich dieses Problem nicht reaktiv lösen lässt. Es muss proaktiv bekämpft werden. Der nächste Lieferketten-Wurm benötigt keinen Zero-Day, sondern lediglich einen unsicheren Workflow und eine unsichere Automatisierung.

In diesem Fall haben wir ihn zuerst entdeckt.