Kompromittierte GitHub Actions von actions-cool liefen neun Tage erneut mit Schadcode

Wer in GitHub-Workflows die Actions actions-cool/issues-helper oder actions-cool/maintain-one-comment über einen Versions-Tag wie @v2.2.1 einbindet, hat zwischen dem 16. und 25. September 2026 sehr wahrscheinlich Schadcode aus der Mini-Shai-Hulud-Kampagne vom Mai im eigenen CI-Runner ausgeführt. Beide Repositories waren nach der Kompromittierung im Mai gesperrt, wurden am 16. September wieder zugänglich und lieferten über die unveränderten Tags erneut die präparierte Version aus. Seit dem 25. September sind sie wieder deaktiviert.

Nicht betroffen sind Workflows, die beide Actions über den vollständigen Commit-SHA einer sauberen Version von vor dem 18. Mai 2026 einbinden, sowie Organisationen, die die Actions gar nicht verwenden. Wer sie per Tag nutzt, sollte heute handeln: Workflows durchsuchen, Läufe seit dem 16. September prüfen und alle Secrets rotieren, auf die diese Workflows Zugriff hatten. Die erste Kampagne rund um den Shai-Hulud-Wurm hatte S-EDV bereits im Artikel Shai-Hulud über gekaperte KI-Coding-Session beschrieben, der aktuelle Fall ist ein neues Ereignis.

Was ist passiert?

Am 18. Mai 2026 hatten Angreifer im Rahmen der Mini-Shai-Hulud-Kampagne die Release-Tags beider actions-cool-Actions auf Commits mit verschleiertem Schadcode umgebogen. Laut dem Security-Anbieter Socket, der den aktuellen Vorfall am 24. September dokumentiert hat, sperrte das GitHub-Sicherheitsteam beide Repositories am 19. Mai. Die Tags selbst wurden dabei nicht bereinigt. Workflows, die die Actions referenzierten, scheiterten ab dann bereits im Schritt „Set up job“ mit der Meldung Repository access blocked, der Schadcode lief also nicht mehr.

Am 16. September 2026, zwischen 11:09 und 18:16 Uhr (MESZ), wurden beide Repositories wieder zugänglich. Warum, ist nicht geklärt. BleepingComputer spricht von einer Reaktivierung durch den Maintainer, Socket nennt eine Anfrage der legitimen Maintainer ausdrücklich nur als eine unbestätigte Möglichkeit. Fest steht: Die Tags zeigten weiter auf den präparierten Stand. Socket belegt das an Workflow-Logs, in denen actions-cool/issues-helper@v2.2.1 auf den Commit a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d auflöst. Der Runner installiert dort über oven-sh/setup-bun die Bun-Laufzeit und führt anschließend bun run $GITHUB_ACTION_PATH/index.js aus. Läufe, die vorher nach wenigen Sekunden scheiterten, dauerten plötzlich 5 bis 11 Minuten und endeten erfolgreich.

Am 25. September meldete Socket, dass beide Repositories erneut deaktiviert sind. Die Seiten zeigen wieder den Hinweis, dass der Zugriff durch GitHub-Mitarbeiter wegen eines Verstoßes gegen die Nutzungsbedingungen gesperrt wurde. Damit lag ein Zeitfenster von rund neun Tagen vor, in dem jeder planmäßige oder ereignisgesteuerte Lauf den Schadcode ausführen konnte.

Wer ist betroffen?

Betroffen sind alle Repositories, in denen ein Workflow eine der beiden Actions per Tag oder Branch referenziert und im Zeitraum vom 16. bis 25. September 2026 gelaufen ist. Laut Socket listet der GitHub-Abhängigkeitsgraph allein für issues-helper rund 15.000 abhängige Repositories. Wie viele davon per Tag statt per Commit-SHA einbinden, hat Socket nach eigener Aussage nicht ermittelt. Die Zahl ist daher eine Obergrenze und keine Opferzahl.

• Betroffen: Einträge wie uses: actions-cool/issues-helper@v2.2.1, @v2, @v3 oder @main in .github/workflows/.
• Betroffen: Workflows mit actions-cool/maintain-one-comment@... per Tag, beide Repositories wurden laut Socket gleichzeitig gesperrt und freigegeben.
• Besonders exponiert: Workflows mit Zeitplan (schedule) oder Triggern auf issues und pull_request, weil sie ohne eigenes Zutun liefen. Bei öffentlichen Repositories kann jeder GitHub-Nutzer per neuem Issue einen Lauf auslösen.
• Nicht betroffen: Einbindung über den vollständigen Commit-SHA einer Version von vor dem 18. Mai 2026.
• Nicht betroffen: Workflows, die im genannten Zeitraum nicht gelaufen sind. Sie scheitern seit dem 25. September wieder beim Job-Setup.

Die Actions dienen der Pflege von Issues und Kommentaren, etwa zum Schließen inaktiver Issues. Solche Hilfs-Workflows werden oft einmal eingerichtet und danach vergessen. Gerade KMU mit wenigen Entwicklern sollten deshalb nicht davon ausgehen, dass sie die Actions nicht nutzen, sondern gezielt suchen.

Wie kritisch ist das?

Für betroffene Repositories ist der Vorfall akut kritisch. Der Schadcode der Mini-Shai-Hulud-Kampagne zielt laut Socket und BleepingComputer auf Tokens, Zugangsdaten und CI/CD-Secrets. Er läuft mit allen Rechten des Workflows, also mit dem GITHUB_TOKEN und allen Secrets, die der Job sehen kann. The Hacker News nennt als Exfiltrationsziel die Domain t.m-kosche[.]com aus der ursprünglichen Kampagne. Ob im September dieselbe Infrastruktur noch aktiv Daten entgegennahm, ist in den Quellen nicht belegt und bleibt offen.

Technisch handelt es sich um eine Kompromittierung der Lieferkette mit Codeausführung im CI-Runner und anschließendem Datenabfluss, nicht um eine Schwachstelle in GitHub selbst. Eine CVE-Nummer gibt es nicht. Das Besondere laut Socket: Die Angreifer mussten nichts Neues tun. Es wurde kein neuer Code veröffentlicht und keine Konfiguration geändert, allein die erneute Freigabe der Repositories reaktivierte den Angriff. Da die Workflows meist täglich laufen, dürfte die Mehrheit der betroffenen Repositories den Schadcode laut Socket innerhalb eines Tages nach dem 16. September ausgeführt haben.

Was sollten Admins jetzt tun?

• Inventar erstellen: Alle eigenen Repositories nach beiden Actions durchsuchen. Lokal im geklonten Repository reicht grep -rnE "actions-cool/(issues-helper|maintain-one-comment)@" .github/workflows/. Für eine ganze Organisation hilft die GitHub CLI mit gh search code "actions-cool/issues-helper" --owner <organisation> und gh search code "actions-cool/maintain-one-comment" --owner <organisation>.
• Referenzen bewerten: Jede Einbindung über Tag oder Branch (zum Beispiel @v2.2.1) als kompromittiert behandeln. Nur ein vollständiger 40-stelliger Commit-SHA einer Version von vor dem 18. Mai 2026 gilt als sicher.
• Actions entfernen oder pinnen: Am einfachsten die Actions ganz entfernen, sie erledigen nur Komfortaufgaben. Wer sie behalten will, pinnt auf einen selbst geprüften sauberen Commit-SHA und nicht auf einen Tag.
• Laufhistorie prüfen: Mit gh run list --workflow <datei>.yml --limit 50 Läufe seit dem 16. September ansehen. Verdächtig sind Läufe, die nach einer Reihe schneller Fehlschläge plötzlich erfolgreich sind und von Sekunden auf mehrere Minuten springen.
• Runner-Logs durchsuchen: Mit gh run view <run-id> --log | grep -nE "setup-bun|bun run|a0c53dd42fc842d2f9276c5a1d4f9a26abe8713d" nach den von Socket genannten Indikatoren suchen.
• Secrets rotieren: Für jeden Workflow, der mit Tag-Referenz ab dem 16. September lief, alle erreichbaren Secrets erneuern: npm- und PyPI-Tokens, Cloud-Zugangsdaten, Deploy-Keys, Registry-Passwörter, Webhook-Tokens. Zusätzlich prüfen, welche Rechte der GITHUB_TOKEN des Jobs hatte.
• Repository-Historie prüfen: Commits, Tags, Releases und neue Workflow-Dateien ab dem 16. September auf unerklärte Änderungen durchsehen. In der Organisation zudem das Audit-Log auf neue Deploy-Keys, Tokens und Mitglieder prüfen.
• Nachgelagerte Systeme prüfen: Wurden mit den gestohlenen Zugangsdaten Pakete veröffentlicht oder Cloud-Ressourcen verändert? Veröffentlichte Paketversionen und Cloud-Protokolle im selben Zeitraum abgleichen.
• Grundsätzlich härten: Alle Actions von Drittanbietern auf Commit-SHAs pinnen, den GITHUB_TOKEN per permissions: auf das Nötigste beschränken und Secrets nur in Jobs bereitstellen, die sie wirklich brauchen. GitHub beschreibt das in seinem Leitfaden zur Absicherung von Actions.

Wer im Anschluss prüfen will, ob Secrets bereits im Code oder in der Historie gelandet sind, kann ergänzend einen Secret-Scanner einsetzen. Eine Anleitung dazu gibt es mit Gitleaks als Docker-Secret-Scanner.

Einordnung für Unternehmen

Der Vorfall zeigt ein Muster, das über diese zwei Actions hinausgeht: Eine Sperre durch die Plattform ist nur eine vorübergehende Eindämmung. Solange ein kompromittierter Tag existiert, kann er jederzeit wieder ausgeliefert werden, ohne dass sich an der eigenen Workflow-Datei etwas ändert. Wer Actions über Tags einbindet, verlässt sich vollständig auf den Zustand eines fremden Repositories. SHA-Pinning nimmt diese Abhängigkeit heraus, schützt aber nur, wenn der gepinnte Commit selbst sauber ist.

Für KMU ist der praktische Hebel klein und wirksam: ein einmaliges Inventar aller verwendeten Actions, konsequentes Pinning und automatische Aktualisierung der gepinnten SHAs etwa über Dependabot oder Renovate. Hilfs-Workflows ohne echten Nutzen gehören gestrichen, denn sie laufen mit denselben Secrets wie der Build. Wie weitreichend Lücken in CI/CD-Pipelines sein können, zeigte S-EDV bereits beim Fall Cordyceps: Kritische CI/CD-Lücken gefährden 300+ GitHub-Repos.

Passende Anleitungen auf S-EDV

• Gitleaks mit Docker: Secrets in Repositories finden
• Shai-Hulud über gekaperte KI-Coding-Session: Hintergrund zur Wurm-Kampagne
• Cordyceps: Kritische CI/CD-Lücken in GitHub-Repositories

Quellen

• Socket: Re-Enabled GitHub Actions Expose Thousands of Repositories to Mini Shai-Hulud (24.09.2026, Update 25.09.2026)
• BleepingComputer: GitHub Actions re-enabled with Mini Shai-Hulud payload still active (26.09.2026)
• The Hacker News: Compromised GitHub Actions Came Back Online and Resumed Executing Mini Shai-Hulud Malware (25.09.2026)
• GitHub Docs: Security hardening for GitHub Actions