Shai Hulud v2 Malware

Die zweite Welle des Shai-Hulud-Lieferkettenangriffs hat nun das Maven-Ökosystem erreicht, nachdem über 830 Pakete im npm-Repository kompromittiert wurden. Forscher identifizierten ein Maven Central-Paket, org.mvnpm:posthog-node:4.18.1, das dieselben schädlichen Komponenten wie die vorherigen npm-Angriffe enthält: den Loader setup_bun.js und die Payload bun_environment.js. Bislang ist dies das einzige bekannte betroffene Java-Paket.

Bemerkenswert ist, dass das Maven-Paket nicht von PostHog veröffentlicht wurde. Stattdessen wurde es durch einen automatisierten mvnpm-Prozess generiert, der npm-Pakete als Maven-Artefakte neu erstellt. Maven Central hat bestätigt, dass alle gespiegelten Kopien zum 25. November 2025 gelöscht wurden und zusätzliche Schutzmaßnahmen implementiert werden, um die erneute Veröffentlichung kompromittierter npm-Komponenten zu verhindern.

Globale Entwicklerwirkung und Angriffsziele

Diese jüngste Welle zielt auf Entwickler weltweit ab und hat zum Ziel, sensible Daten wie die folgenden zu stehlen:

• API-Schlüssel
• Cloud-Zugangsdaten
• npm- und GitHub-Tokens

Es ermöglicht zudem tiefgreifende Kompromittierungen der Lieferkette auf wurmartige, sich selbst replizierende Weise. Diese Version von Shai-Hulud ist heimtückischer, aggressiver und zerstörerischer als die ursprüngliche Variante vom September. Durch die Kompromittierung von npm-Maintainer-Konten können Angreifer Trojanerpakete veröffentlichen, die Entwicklerrechner mit Hintertüren versehen und automatisch nach Geheimnissen suchen, um diese in GitHub-Repositories zu exfiltrieren.

Funktionsweise der Malware: Duale Arbeitsabläufe und Tarntechniken

Der Angriff nutzt zwei bösartige Arbeitsabläufe aus:

• Selbstgehostete Runner-Registrierung: Ermöglicht die Ausführung beliebiger Befehle, sobald eine GitHub-Diskussion geöffnet wird.
• Workflow zum Sammeln von Geheimnissen: Sammelt systematisch Zugangsdaten und überträgt sie an GitHub.
• Zu den wichtigsten Verbesserungen in Shai-Hulud v2 gehören:
• Verwendung der Bun-Laufzeitumgebung zur Verschleierung der Kernlogik
• Erweiterung der Infektionsgrenze von 20 auf 100 Packungen
• Zufällig generierte Exfiltrations-Repositories auf GitHub, um der Erkennung zu entgehen

Bislang sind über 28.000 Repositories betroffen, was das enorme Ausmaß und die Heimlichkeit der Kampagne verdeutlicht.

Ausgenutzte Schwachstellen und Mechanismen der Lieferkette

Angreifer nutzen Fehlkonfigurationen der CI-Pipeline in GitHub Actions-Workflows aus, insbesondere bei den Triggern `pull_request_target` und `workflow_run`. Ein einziger falsch konfigurierter Workflow kann ein Repository zum Ausgangspunkt für Schadcode machen und so dessen rasante Verbreitung ermöglichen.

Der Angriff zielte auf Projekte ab, die mit AsyncAPI, PostHog und Postman in Verbindung stehen, und setzt eine umfassendere Kampagne fort, die mit dem S1ngularity-Angriff im August 2025 begann, der mehrere Nx-Pakete auf npm betraf.

Die Folgen: Durchgesickerte Geheimnisse und systemisches Risiko

Eine Analyse des Wahlkampfs zeigt:

• Hunderte von GitHub-Zugriffstoken und Cloud-Zugangsdaten von AWS, Google Cloud und Microsoft Azure wurden exfiltriert.
• Mehr als 5.000 Dateien mit Geheimnissen wurden auf GitHub hochgeladen.
• Von 11.858 einzigartigen Geheimnissen, die in 4.645 Repositories identifiziert wurden, waren am 24. November 2025 noch 2.298 gültig und öffentlich zugänglich.

Dies zeigt, wie ein einziger kompromittierter Maintainer einen Kaskadeneffekt auslösen und Tausende von nachgelagerten Anwendungen infizieren kann.

Empfehlungen für Entwickler

Um das Risiko zu minimieren, sollten Entwickler Folgendes tun:

• Alle API-Schlüssel, Tokens und Anmeldeinformationen regelmäßig wechseln.
• Prüfen und Entfernen kompromittierter Abhängigkeiten
• Installieren Sie saubere Paketversionen neu.
• Härten Sie CI/CD-Umgebungen mit minimalen Zugriffsrechten, Geheimnisprüfung und automatisierter Richtliniendurchsetzung ab.

Shai-Hulud betont, dass die moderne Software-Lieferkette weiterhin hochgradig angreifbar ist. Angreifer nutzen nach wie vor Sicherheitslücken bei der Veröffentlichung, Paketierung und Bereitstellung von Open-Source-Software aus, oft ohne dabei auf Zero-Day-Schwachstellen zurückzugreifen. Der effektivste Schutz erfordert ein Umdenken in der Art und Weise, wie Software entwickelt, geteilt und genutzt wird.