Nur einen Tag ist es her, dass der zweite Shai Hulud Supply-Chain-Angriff das Ökosystem erschütterte, und stündlich werden immer noch neue Benutzer und Organisationen kompromittiert. Während wir die Folgen analysieren, beginnen wir, den anfänglichen Infektionsvektor aufzudecken, den die Angreifer nutzten, um große Projekte wie AsyncAPI, PostHog und Postman zu kompromittieren, und es wird deutlich, dass wir das volle Ausmaß dieser Kampagne noch nicht gesehen haben. Durch die Ausnutzung subtiler, aber mächtiger Schwachstellen in GitHub Actions Workflows demonstrierten die Angreifer eine beunruhigende Entwicklung ihrer Liefermethoden. Dies ist eine starke Erinnerung daran, dass sich unsere Verteidigung ebenso schnell weiterentwickeln muss und dass die Sicherheit des Open-Source-Ökosystems von der kontinuierlichen Härtung der Infrastruktur abhängt, die wir oft als selbstverständlich ansehen.
Zeitachse der Shai-Hulud-Kampagne
- 27. August - Wir veröffentlichen unseren Bericht, der die S1ngularity-Kampagne detailliert beschreibt, die mehrere nx-Pakete auf npm zum Ziel hatte.
- 16. September - Der Angreifer schlägt erneut zu, startet die erste Welle der Shai-Hulud-Angriffe.
- 18. September - Wir veröffentlichen eine Folgeanalyse, die tiefer in die technischen Besonderheiten und das frühe Payload-Verhalten der Kampagne eintaucht.
- 24. November - Ein zweiter Angriff erfolgt, von den Angreifern als „Second Coming“ bezeichnet, zeitlich abgestimmt kurz vor nps Frist zur Widerrufung alter Tokens.
- 25. November - Wir decken den anfänglichen Angriffsvektor der Angreifer durch anfällige GitHub Actions Workflows in Projekten wie AsyncAPI, PostHog und Postman auf.
Eine kurze Auffrischung
Seit dem Nx-Angriff und der Shai-Hulud-Attacke wissen wir, dass der Angreifer GitHub Actions Workflows missbraucht, um Daten über webhook.site-Links zu exfiltrieren. Bei früheren Vorfällen war die Methode unkompliziert. Der Angreifer platzierte eine absichtliche Backdoor in einer Workflow-Datei, und diese Backdoor übertrug still und heimlich sensible Informationen, einschließlich Anmeldeinformationen, an einen vom Angreifer kontrollierten Endpunkt.
Was wir in der neuesten Welle der Shai-Hulud-Kampagne sehen, ist fortschrittlicher. Anstatt Backdoors direkt einzuschleusen, nutzen die Angreifer nun Schwachstellen in bestehenden GitHub Actions Workflows aus, um ihren Angriff auszuführen. Diese Technikverlagerung ermöglichte es ihnen, Projekte wie AsyncAPI, PostHog und Postman beim gestrigen Shai-Hulud-Angriff zu kompromittieren.
Unsere Untersuchung begann, als wir mehrere verdächtige Uploads auf NPM bemerkten, die mit unerwarteten Benutzernamen wie „codespace“ und „runner“ verbunden waren. Diese Uploads fielen sofort als Anomalien auf, und eine tiefere Analyse zeigte, dass sie alle wahrscheinlich manuell vom Angreifer durch die Ausnutzung von GitHub Actions platziert wurden. Wir wurden später von einer dritten Partei über eine verwandte bösartige OpenVSX-Erweiterung mit einem ähnlichen Muster informiert. Diese Entdeckung bestätigte, dass die Angreifer ihre Methoden weiterentwickelt haben und nun CI-Fehlkonfigurationen als Teil ihrer Angriffskette nutzen.
Wie der Angreifer GitHub Actions Schwachstellen nutzte
GitHub Actions Workflows sind automatisierte Skripte, die innerhalb eines Repositories ausgeführt werden, um Aufgaben wie Testen, Erstellen, Veröffentlichen oder Verwalten von Pull Requests zu übernehmen. Sie sind leistungsstark und flexibel, doch diese Leistung birgt Risiken, insbesondere wenn Workflows ohne ein vollständiges Verständnis dafür konfiguriert werden, wie sie nicht vertrauenswürdigen Code ausführen.
Bestimmte Workflow-Trigger, einschließlich pull_request_target und workflow_run, können bei Fehlkonfiguration gefährlich werden. Genau das geschah im Fall von PostHog, wie im Screenshot gezeigt. Das Problem wurde erstmals durch Adnan Khan, einem Sicherheitsforscher, der den anfälligen Workflow in einem X-Post hervorhob, einer breiteren Öffentlichkeit bekannt. Der Angriff wurde wahrscheinlich durch eine Schwachstelle in der .github/workflows/auto-assign-reviewers.yml Workflow-Datei verursacht. Diese Datei verwendete den riskanten pull_request_target Trigger auf eine Weise, die es ermöglichte, dass von jedem neuen Pull Request bereitgestellter Code während des CI-Laufs ausgeführt wurde. Die Schwachstelle wurde erstmals am 11. September 2025 durch einen zusammengeführten Pull Request eingeführt und blieb bis zum Shai-Hulud-Angriff verfügbar. Insgesamt war das Problem 74 Tage lang vorhanden, bevor der Angreifer es ausnutzte.
Ein ähnliches Muster zeigt sich im AsyncAPI-Repository. Wir stellten fest, dass ihre .github/workflows/auto-changeset.yml Datei eine anfällige Konfiguration enthielt, die am 9. September 2025 hinzugefügt wurde. Das AsyncAPI-Team hat die Datei seitdem auf unsere Empfehlung hin entfernt, aber die Konfiguration war lange genug verfügbar, damit der Angreifer dieses Projekt in die Kampagne aufnehmen konnte.
Es ist bemerkenswert, dass eines dieser Projekte bereits ein PR-Scanning-Tool verwendete, es aber dennoch nicht gelang, die in den GitHub Actions Workflows verborgenen Schwachstellen zu erkennen. Im Fall von PostHog warnte GitHub vor der Schwachstelle, doch diese Warnung blieb unbeachtet. Dies unterstreicht die Notwendigkeit von Sicherheitstools, die Probleme in einer Vielzahl von Systemen und Sprachen erkennen und kennzeichnen können, einschließlich CI-Konfigurationsschwachstellen. Sobald ein Angreifer einen ausnutzbaren Workflow in einem Projekt identifiziert, kann diese einzelne Schwachstelle als Ausgangspunkt für einen Angriff dienen, der sich in einem bisher unbekannten Ausmaß verbreitet, wie der Shai-Hulud-Wurm gezeigt hat.
Was Sie wissen sollten und welche Maßnahmen zu ergreifen sind
Da sich diese Bedrohungen ständig weiterentwickeln, wird es immer wichtiger zu verstehen, wie Schwachstellen in GitHub Actions Workflows nicht nur Ihr eigenes Projekt, sondern jedes damit verbundene Projekt und jeden Benutzer gefährden können. Eine einzige Fehlkonfiguration kann ein Repository zu einem Patient Null für einen sich schnell ausbreitenden Angriff machen und einem Gegner die Möglichkeit geben, bösartigen Code durch automatisierte Pipelines zu schleusen, auf die Sie sich täglich verlassen. Entwickelnde können sich nur gegen das verteidigen, was sie kennen, daher ist das Bewusstsein für gefährliche Workflow-Muster wie pull_request_target und workflow_run unerlässlich. Eine weitere Option ist die Nutzung einer Sicherheitsplattform wie Aikido, die Repositories und eingehende Pull Requests automatisch auf diese Art von Schwachstellen scannt.
Es ist ebenso wichtig, sich der Schwachstellen in den von Ihnen installierten Abhängigkeiten bewusst zu bleiben. Selbst wenn Ihre eigenen Workflows sicher sind, können kompromittierte Pakete in vorgelagerten Systemen weiterhin Risiken einführen. Hier sind die SCA-Funktionen von Aikido, die Intel Vulnerability Database und die Package Health-Erkenntnisse besonders nützlich, da sie Teams helfen, Probleme frühzeitig zu erkennen und zu verstehen, ob die von ihnen verwendeten Bibliotheken Anzeichen von Kompromittierung oder verdächtiger Aktivität aufweisen.
Schließlich kann ein Tool, das Malware in Echtzeit beim Auftreten stoppen kann, eine ernsthafte Infektion verhindern. Dies ist die Idee hinter Aikido Safe Chain, einem kostenlosen Tool, das npm umschließt und sowohl KI als auch menschliche Malware-Forscher einsetzt, um die neuesten Supply-Chain-Risiken zu erkennen und zu blockieren, bevor sie in Ihre Umgebung gelangen.
