Der bislang vor allem in der npm-Welt beobachtete Schadcode Shai-Hulud hat ein neues Ziel erreicht: das zentrale Java-Repository Maven Central. Damit wächst der Druck auf Entwicklungsteams, die sowohl mit JavaScript- als auch mit Java-Abhängigkeiten arbeiten, ihre Sicherheitsmaßnahmen in der Software-Lieferkette deutlich zu verschärfen.
Shai-Hulud in Maven Central: Ausweitung der Supply-Chain-Kampagne
Sicherheitsspezialisten von Socket identifizierten in Maven Central das Paket org.mvnpm:posthog-node:4.18.1, das zwei für Shai-Hulud typische Komponenten enthält: den Loader setup_bun.js und den Haupt-Payload bun_environment.js. Es handelt sich um dieselben Dateien, die bereits in einer zweiten Angriffswelle in der npm-Registry eingesetzt wurden.
Bemerkenswert ist, dass nicht der ursprüngliche Java-Code kompromittiert wurde. Das fragliche Artefakt wurde automatisiert über den Prozess mvnpm erzeugt, der npm-Pakete in Maven-Artefakte gespiegelt bereitstellt. Damit hat der Angreifer den Weg über ein Mirror- bzw. Repackaging-Verfahren genutzt, um Java-Projekte über JavaScript-Abhängigkeiten zu erreichen – ein typisches Muster moderner Software-Supply-Chain-Angriffe.
Die Betreiber von Maven Central haben angekündigt, zusätzliche Filter einzuführen, um die erneute Verpackung bereits bekannter kompromittierter npm-Komponenten zu blockieren. Solche Gegenmaßnahmen reduzieren das unmittelbare Risiko, können aber das strukturelle Problem – das hohe implizite Vertrauen in Paket-Repositories und Spiegelmechanismen – nur begrenzt lösen.
Shai-Hulud v2: Verdeckter Fokus auf Geheimnisdiebstahl
Nach Erkenntnissen mehrerer Sicherheitsteams wurde der PostHog-Stack sowohl im npm- als auch im Maven-Kontext kompromittiert. In allen beobachteten Fällen kam derselbe Payload zum Einsatz: Shai-Hulud Version 2. Diese zweite Generation ist deutlich stärker auf Tarnung und den Diebstahl sensibler Zugangsdaten von Entwicklern und DevOps-Teams ausgelegt.
Laut Berichten von Wiz und weiteren Beteiligten der Analyse waren bis zum 24. November 2025 bereits mehr als 25 000 GitHub-Repositories von der Veröffentlichung entwendeter Geheimnisse betroffen. Hinzu kamen rund 1000 neue Repositories alle 30 Minuten, die weitere geleakte Zugangsdaten enthielten. Solche Zahlen verdeutlichen, wie schnell sich kompromittierte Secrets in offenen Ökosystemen vervielfältigen und von weiteren Angreifern ausgenutzt werden können.
Technische Analyse: setup_bun.js und bun_environment.js
Untersuchungen von Step Security zeigen, dass der Wurm im Kern aus zwei Dateien besteht. setup_bun.js fungiert als Dropper und tarnt sich als harmloser Installer für die JavaScript-Laufzeitumgebung Bun. Der eigentliche Schadcode steckt im rund 10 MB großen File bun_environment.js, das umfangreiche Obfuskationstechniken nutzt, um die Analyse zu erschweren.
Der Payload enthält eine hex-kodierte Zeichenkette mit Tausenden Einträgen, eine separate Schleife zur künstlichen Komplexitätssteigerung sowie eine obfuskierte Funktion, die die gespeicherten Codefragmente schrittweise zur Laufzeit rekonstruiert. Diese Kombination reduziert die Wirksamkeit klassischer statischer Analysen, Antiviren-Engines und SCA-Tools (Software Composition Analysis), die stark auf Mustererkennung und Signaturen angewiesen sind.
Nach erfolgreicher Initialisierung führt Shai-Hulud eine mehrstufige Angriffskette aus, deren Schwerpunkt auf der Exfiltration von Secrets liegt. Abgegriffen werden unter anderem GitHub- und npm-Tokens sowie Zugangsdaten für AWS, Google Cloud und Microsoft Azure. Gelingt es dem Wurm nicht, vier zentrale Schritte – Authentifizierung bei GitHub, Anlegen eines Repositories, Auffinden von GitHub- und npm-Tokens – erfolgreich durchzuführen, wechselt er in eine destruktive Phase und überschreibt den kompletten Home-Ordner der betroffenen Maschine.
Missbrauch von GitHub Actions: Fehlkonfigurationen als Einfallstor
Aikido Security dokumentierte, dass die Angreifer gezielt unsichere CI/CD-Konfigurationen in GitHub Actions ausnutzten. Besonderes Augenmerk lag auf Workflows mit den Triggern pull_request_target und workflow_run, die in vielen Projekten übermäßig hohe Rechte besitzen. Durch solche Konfigurationen konnten Angreifer auf geschützte Secrets zugreifen und beliebigen Code im Kontext fremder Repositories ausführen.
In der Folge wurden mehrere prominente Open-Source-Projekte kompromittiert, darunter AsyncAPI, Postman und PostHog. Die erbeuteten Zugangsdaten wurden automatisiert in GitHub-Repositories mit der Beschreibung „Sha1-Hulud: The Second Coming“ veröffentlicht. Diese öffentliche Ablage erleichterte die massive Sammlung, Korrelation und Weiterverwendung der gestohlenen Secrets durch unterschiedliche Akteure.
Gemeinsame Auswertungen von GitGuardian, OX Security und Wiz kommen zu dem Ergebnis, dass im Rahmen der Kampagne Hunderte GitHub-Tokens und Cloud-Zugangsdaten offengelegt wurden. Es wurden über 5000 Dateien mit gestohlenen Secrets auf GitHub geladen. Eine Analyse von 4645 Repositories identifizierte 11 858 eindeutige Geheimnisse, von denen 2298 am 24. November 2025 noch gültig und öffentlich zugänglich waren – ein deutliches Indiz für langsame oder unvollständige Incident-Response-Prozesse.
Lehren für die Sicherheit der Software-Lieferkette
Der aktuelle Shai-Hulud-Fall zeigt, wie anfällig moderne Software-Lieferketten für Kettenreaktionen sind: Die Kompromittierung eines einzigen populären Pakets oder eines CI/CD-Workflows kann Risiken für Tausende abhängige Projekte erzeugen. Studien von Organisationen wie ENISA und Sonatype haben in den letzten Jahren wiederholt darauf hingewiesen, dass die Zahl der Supply-Chain-Vorfälle deutlich schneller wächst als klassische Schwachstellen in Applikationen.
Konkrete Schutzmaßnahmen für Unternehmen und Entwickler
Organisationen sollten ihre Vertrauensmodelle gegenüber Paket-Repositories und Mirrors grundlegend überdenken. Dazu gehört der Einsatz von SCA-Tools mit Block- oder Allow-Listen kompromittierter Artefakte, die Überprüfung von Maintainer-Accounts sowie, wo möglich, kryptografische Verifikation (z. B. Signaturen) für Dependencies.
Für GitHub Actions und andere CI/CD-Plattformen ist das Prinzip der minimalen Rechte entscheidend. Hochriskante Trigger wie pull_request_target sollten nur mit zusätzlicher Validierung (z. B. manuellem Review, isolierten Test-Workflows) genutzt werden. Secrets sollten strikt auf das notwendige Minimum begrenzt und bevorzugt über kurzlebige, OIDC-basierte Zugriffstokens statt statischer Cloud-Schlüssel bereitgestellt werden.
Darüber hinaus sind kontinuierliches Secrets-Scanning in Repositories und CI-Logs, automatisierte Rotation kompromittierter Zugangsdaten sowie klare Incident-Response-Pläne essenziell. Die Orientierung an etablierten Rahmenwerken wie dem NIST Secure Software Development Framework (SSDF) oder Initiativen wie SLSA (Supply-chain Levels for Software Artifacts) kann helfen, Sicherheitsanforderungen systematisch in den Entwicklungsprozess zu integrieren.
Die aktuelle Shai-Hulud-Welle macht deutlich, dass Sicherheit in der Software-Lieferkette kein Randthema mehr ist. Entwicklungsteams, Security-Verantwortliche und Betreiber von Paket- und CI/CD-Infrastrukturen sollten jetzt handeln: Abhängigkeitsketten sichtbar machen, Vertrauensgrenzen nachschärfen und Sicherheitskontrollen konsequent automatisieren. Wer diese Schritte frühzeitig umsetzt, reduziert nicht nur das Risiko ähnlicher Kampagnen, sondern stärkt nachhaltig die Resilienz seiner gesamten Entwicklungs- und Betriebslandschaft.
