GitHub-Angriff zielt mit Command Injection auf 61 Repositories und CI/CD-Secrets

Eine koordinierte Supply-Chain-Angriffskampagne hat am 1. September 2026 auf 61 öffentliche GitHub-Repositories gezielt. Laut einer Untersuchung des Sicherheitsunternehmens Radware, die am 29. Oktober veröffentlicht wurde, veröffentlichten die Angreifer 83 bösartige Einträge — Issues, Pull Requests und Kommentare — mit dem Ziel, Befehle in Continuous-Integration- und Continuous-Delivery-Umgebungen (CI/CD) auszuführen und Entwicklungsgeheimnisse zu stehlen.

Was geschah

Die Aktivität war zeitlich stark konzentriert: 77 der 83 bösartigen Einträge wurden innerhalb von etwa 43 Minuten veröffentlicht, zwischen 11:26 und 12:10 Uhr UTC am 1. September. Eine zweite Welle mit sechs Einträgen folgte später am selben Tag. Zu den Zielen gehörten bekannte Projekte wie Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet und PX4-Autopilot — was nicht bedeutet, dass all diese Projekte kompromittiert wurden: Die Auswirkungen hingen von den Berechtigungen und der Konfiguration des jeweiligen Workflows ab.

Wie der Angriff funktionierte

Der Mechanismus war Shell-Command-Injection über nicht vertrauenswürdige Inhalte, die von GitHub Actions verarbeitet wurden. Die Angreifer betteten Bash-Befehlsersetzungsausdrücke, geschrieben als $(), in Titel von Issues und Pull Requests ein. Wenn ein Workflow diese Inhalte direkt in Shell-Code einfügte, interpretierte Bash den Ausdruck als auszuführenden Befehl.

Die Payload sammelte die Umgebungsvariablen des Prozesses mit dem Befehl env, kodierte das Ergebnis in Base64 und versuchte, es per HTTP an einen vom Angreifer kontrollierten Server unter 54.205.16.142, Port 8443, zu senden. Der Angriff konnte gelingen, selbst wenn das Issue oder der Pull Request nie genehmigt, nie gemergt oder wenige Minuten nach dem Einreichen geschlossen wurde.

Was bestätigt wurde — und was nicht

Radware analysierte Protokolle realer Läufe und fand direkte Belege dafür, dass der bösartige Befehl in zwei Fällen innerhalb der Automatisierungsumgebung ausgeführt wurde: im Pull Request Nr. 28488 von PX4-Autopilot und in einem Issue des Projekts workout-cool. Andererseits bestätigte die Untersuchung nicht, dass Geheimnisse gestohlen, Schreibrechte auf Repositories erlangt, Quellcode verändert oder ausgelieferte Versionen kompromittiert wurden. GitHub-Actions-Secrets stehen nicht automatisch jedem Workflow zur Verfügung, und die Befehlsausführung allein beweist nicht, dass Zugangsdaten exfiltriert wurden.

Radware identifizierte außerdem GitHub-Konten mit zuvor legitimer Entwicklungsaktivität, die zur Verbreitung des Angriffs genutzt wurden, sowie einen Nutzer, der öffentlich erklärte, die ihm zugeschriebene bösartige Aktivität nicht erstellt zu haben.

Was Maintainer tun sollten

Für Projekte, die GitHub Actions nutzen, empfehlen die Forscher, von Nutzern gelieferte Inhalte niemals direkt in Shell-Skripte zu interpolieren: Werte sollten über Umgebungsvariablen übergeben werden. Maintainer öffentlicher Repositories sollten Issues und Pull Requests prüfen, die am 1. September 2026 veröffentlicht wurden, und vorsorglich Zugangsdaten rotieren, die in CI/CD-Umgebungen offengelegt worden sein könnten.

Auch auf Geekiki: WordPress-Schwachstelle bei Updates ausgenutzt; CISA setzt Frist bis 6. November.

Bildnachweis: Illustration von Radware, veröffentlicht im offiziellen Blog des Unternehmens zur Untersuchung.

Quellen

Transparenz: Dieser Artikel wurde mit Unterstützung künstlicher Intelligenz auf Grundlage öffentlicher Quellen im Internet erstellt und anhand der unten zitierten Originalquellen geprüft. Bitte konsultieren Sie immer die Originalquellen, um die Details zu bestätigen.

Muse