Nur einen Tag ist vergangen, seit sich der zweite Shai-Hulud-Angriff auf die Lieferkette im gesamten Ökosystem ausgebreitet hat, und jede Stunde werden immer noch neue Nutzer und Organisationen kompromittiert. Während wir die Folgen untersuchen, beginnen wir, den ursprünglichen Infektionsvektor aufzudecken, den die Angreifer genutzt haben, um große Projekte wie AsyncAPI, PostHog und Postman zu kompromittieren, und es wird deutlich, dass wir noch nicht das gesamte Ausmaß dieser Kampagne gesehen haben. Durch die Ausnutzung subtiler, aber leistungsstarker Schwachstellen in GitHub Actions-Workflows haben die Angreifer eine beunruhigende Weiterentwicklung ihrer Angriffsmethoden demonstriert. Dies ist eine eindringliche Mahnung, dass unsere Abwehrmaßnahmen ebenso schnell weiterentwickelt werden müssen und dass die Sicherheit des Open-Source-Ökosystems von der kontinuierlichen Stärkung der Infrastruktur abhängt, die wir oft als selbstverständlich ansehen.
Zeitleiste der Shai-Hulud-Kampagne
- 27. August – Wir veröffentlichen unseren Bericht über die S1ngularity-Kampagne, die mehrere nx-Pakete auf npm zum Ziel hatte.
- 16. September – Der Angreifer schlägt erneut zu und startet die erste Angriffswelle der Shai-Hulud.
- 18. September – Wir veröffentlichen eine Folgeanalyse, in der wir uns eingehender mit den technischen Besonderheiten der Kampagne und dem frühen Verhalten der Payload befassen.
- 24. November – Es kommt zu einem zweiten Angriff, der von den Angreifern als „Second Coming“ bezeichnet wird und zeitlich kurz vor Ablauf der Frist von npm für die Sperrung alter Token stattfindet.
- 25. November – Wir decken den ursprünglichen Angriffsvektor der Angreifer auf, der über anfällige GitHub-Actions-Workflows in Projekten wie AsyncAPI, PostHog und Postman erfolgte.
Eine kurze Auffrischung
Seit dem Nx-Hack und dem Shai-Hulud-Angriff wissen wir, dass der Angreifer GitHub-Actions-Workflows missbraucht hat, um Daten über webhook.site-Links zu exfiltrieren. Bei früheren Vorfällen war die Methode recht einfach. Der Angreifer platzierte eine absichtliche Hintertür in einer Workflow-Datei, über die sensible Informationen, darunter Anmeldedaten, unbemerkt an einen vom Angreifer kontrollierten Endpunkt übertragen wurden.
Was wir in der jüngsten Welle der Shai-Hulud-Kampagne beobachten, ist noch ausgefeilter. Anstatt direkt Hintertüren einzubauen, nutzen die Angreifer nun Schwachstellen in bestehenden GitHub-Actions-Workflows aus, um ihre Angriffe auszuführen. Diese veränderte Technik ermöglichte es ihnen, Projekte wie AsyncAPI, PostHog und Postman im Rahmen des gestrigen Shai-Hulud-Angriffs 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 eingehendere Analyse ergab, dass sie wahrscheinlich alle manuell vom Angreifer durch Ausnutzung von GitHub Actions erstellt worden waren. Später wurden wir von einem Dritten ü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 die Schwachstellen von GitHub Actions ausnutzte
GitHub Actions-Workflows sind automatisierte Skripte, die innerhalb eines Repositorys ausgeführt werden, um Aufgaben wie Testen, Erstellen, Veröffentlichen oder Verwalten von Pull-Anfragen zu erledigen. Sie sind leistungsstark und flexibel, aber diese Leistungsfähigkeit birgt auch Risiken, insbesondere wenn Workflows konfiguriert werden, ohne dass vollständig verstanden wird, wie sie nicht vertrauenswürdigen Code ausführen.
Bestimmte Workflow-Trigger, darunter pull_request_Ziel und Workflow ausführen, kann bei falscher Konfiguration gefährlich werden. Genau das ist im Fall von PostHog passiert, wie der Screenshot zeigt. Das Problem wurde erstmals durch Adnan Khan, ein Sicherheitsforscher, der in einem X-Beitrag auf den anfälligen Arbeitsablauf hingewiesen hat. Der Angriff wurde wahrscheinlich durch eine Schwachstelle innerhalb des .github/workflows/auto-assign-reviewers.yml Workflow. Diese Datei verwendete das riskante pull_request_Ziel auslösen, sodass der von jedem neuen Pull-Request bereitgestellte Code während des CI-Laufs ausgeführt werden konnte. Die Schwachstelle wurde erstmals am 11. September 2025 durch einen zusammengeführten Pull-Request eingeführt und blieb bis zum Shai-Hulud-Angriff bestehen. Insgesamt bestand das Problem 74 Tage lang, bevor es vom Angreifer ausgenutzt wurde.
Ein ähnliches Muster zeigt sich im AsyncAPI-Repository. Wir haben festgestellt, dass deren .github/Workflows/auto-changeset.yml Die Datei enthielt eine anfällige Konfiguration, 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 erwähnenswert, dass eines dieser Projekte bereits ein PR-Scanning-Tool einsetzte, dennoch gelang es nicht, die in den GitHub Actions-Workflows versteckten Schwachstellen zu erkennen. Im Fall von PostHog warnte GitHub vor der Schwachstelle, aber diese Warnung wurde nicht beachtet. Dies unterstreicht die Notwendigkeit von Sicherheitstools, die Probleme in einer Vielzahl von Systemen und Sprachen erkennen und melden können, einschließlich Schwachstellen in der CI-Konfiguration. Sobald ein Angreifer einen ausnutzbaren Workflow in einem Projekt identifiziert hat, kann diese einzelne Schwachstelle als Ausgangspunkt für einen Angriff dienen, der sich in einem bisher unbekannten Ausmaß ausbreitet, wie der Shai-Hulud-Wurm gezeigt hat.
Was Sie wissen sollten und welche Maßnahmen Sie ergreifen sollten
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 alle damit verbundenen Projekte und Benutzer gefährden können. Eine einzige Fehlkonfiguration kann ein Repository zum Ausgangspunkt für einen sich schnell ausbreitenden Angriff machen und einem Angreifer die Möglichkeit geben, bösartigen Code über automatisierte Pipelines zu verbreiten, auf die Sie sich täglich verlassen. Entwickler können sich nur gegen das verteidigen, was sie kennen. Daher ist es wichtig, sich gefährlicher Workflow-Muster wie pull_request_Ziel und Workflow ausführen ist unerlässlich. Eine weitere Option ist die Verwendung einer Sicherheitsplattform wie Aikido Repositorys und eingehende Pull-Anfragen automatisch auf solche Schwachstellen überprüft.
Ebenso wichtig ist es, sich der Schwachstellen in den von Ihnen installierten Abhängigkeiten bewusst zu sein. Selbst wenn Ihre eigenen Arbeitsabläufe sicher sind, können kompromittierte Pakete aus dem Upstream dennoch Risiken mit sich bringen. Hier sind SCA Aikido, die Intel Vulnerability Database und die Package Health Insights besonders nützlich, da sie Teams dabei helfen, Probleme frühzeitig zu erkennen und zu verstehen, ob die von ihnen verwendeten Bibliotheken Anzeichen von Kompromittierung oder verdächtigen Aktivitäten aufweisen.
Schließlich kann ein Tool, das Malware in Echtzeit stoppt, sobald sie auftritt, eine schwerwiegende Infektion verhindern. Das ist die Idee hinter Aikido Chain, einem kostenlosen Tool, das npm umgibt und sowohl KI als auch menschliche Malware-Forscher einsetzt, um die neuesten Risiken in der Lieferkette zu erkennen und zu blockieren, bevor sie in Ihre Umgebung gelangen.
Sichern Sie Ihre Software jetzt.
.avif)
