Shai-Hulud 2.0: Ein Wurm frisst sich durch die Software-Supply-Chain

Ende 2025 sorgt ein neuer, hochaggressiver Software-Wurm namens Shai-Hulud 2.0 für Aufsehen in der Entwickler-Community. Der Wurm frisst sich durch die Supply Chain moderner Software – konkret durch das Ökosystem der npm-Pakete, die Herzstücke vieler Web- und Cloud-Anwendungen sind. In nur wenigen Tagen wurden hunderte npm-Bibliotheken mit bösartigem Code verseucht und über 25.000 GitHub-Repositories kompromittiert. [Analyse]

Check Point Research bezeichnet die zweite Shai-Hulud-Welle als „einen der umfangreichsten und schnellsten npm-Supply-Chain-Angriffe der letzten Jahre", da zwischen dem 21. und 23. November 2025 hunderte Pakete und über 25.000 GitHub-Repositories binnen Stunden kompromittiert wurden. Dieser Beitrag erklärt, wie Shai-Hulud 2.0 technisch funktioniert, welche Risiken bestehen und – ganz wichtig – welche konkreten Schritte Sie jetzt ergreifen können.

1. Ausgangslage: Warum Shai-Hulud 2.0 alle betrifft

npm ist der zentrale Paketdienst für JavaScript- und TypeScript-Bibliotheken. Wenn Entwickler ein npm-Paket installieren, vertrauen sie darauf, dass dieses Paket – und sämtliche indirekten Abhängigkeiten – sauber und sicher sind. Ein Supply-Chain-Angriff wie dieser bricht dieses Vertrauen: Er schleust Malware in die Lieferkette ein, sodass selbst etablierte Open-Source-Pakete plötzlich zur Gefahr werden.

Für Entscheider ohne tiefes Dev-Wissen sei betont: Eine Lücke in der Software-Lieferkette kann sich rasch durch zig Projekte und Organisationen fortpflanzen. npm ist eine der größten Code-Drehscheiben der Welt – selbst ein kleines kompromittiertes Paket kann tausende Anwendungen beeinflussen. [Research]

Aber es gibt auch eine gute Nachricht: Mit einigen grundlegenden Security-Maßnahmen hätten viele Organisationen den Schaden deutlich begrenzen können. Im Folgenden erklären wir, wie Shai-Hulud 2.0 technisch funktioniert und welche konkreten Schritte Sie jetzt ergreifen können.

2. Rückblick: Von Shai-Hulud 1 zu 2.0

Shai-Hulud 2.0 ist nicht aus dem Nichts aufgetaucht – bereits im September 2025 erschütterte die erste Shai-Hulud-Kampagne die JavaScript-Welt.

2.1 Was Shai-Hulud 1 vorbereitete

Die erste Kampagne nutzte gestohlene Zugangskennungen von Paket-Maintainern, um automatisch manipulierte Versionen ihrer Pakete auf npm zu veröffentlichen. [Research] Bemerkenswert war die Kombination aus Credential Theft und Self-Spreading:

• Die Malware stahl GitHub-PATs, Cloud-Keys und npm-Tokens
• Gestohlene Zugangsdaten wurden in einem öffentlichen GitHub-Repo namens „Shai-Hulud" abgelegt
• GitHub-Action-Workflows wurden installiert, die fortlaufend Geheimnisse exfiltrierten
• Geschätzter Schaden durch Kryptowährungsdiebstahl: ~50 Mio. US$

2.2 Was Shai-Hulud 2.0 so gefährlich macht

Shai-Hulud 2.0 („The Second Coming") baut auf diesen Ideen auf, geht aber deutlich weiter: [Analyse]

• Automatisierte Kompromittierung: Gestohlene npm-Tokens werden genutzt, um hunderte Paket-Updates zu veröffentlichen, ohne dass die eigentlichen Maintainer davon wissen.
• Ausnutzung von Lifecycle-Skripten: Ein preinstall-Hook sorgt dafür, dass der Wurm schon bei npm install ausgeführt wird.
• Versteckter Code via Bun: Der Schadcode wird über die alternative Laufzeit Bun ausgeführt, die von vielen Security-Tools noch nicht überwacht wird.
• Wurm-Eigenschaft: Gefundene npm-Tokens werden genutzt, um weitere Pakete desselben Maintainers zu verseuchen – die Supply Chain selbst wird zum Botnetz.

3. Funktionsweise: Schritt für Schritt erklärt

Shai-Hulud 2.0 kombiniert altbewährte Techniken mit neuen Tricks zu einem mehrstufigen Angriff. Der komplette Ablauf lässt sich auf acht Kernschritte herunterbrechen: [Technische Analyse]

3.1 Credential Harvesting im Detail

Sobald bun_environment.js aktiv ist, beginnt Shai-Hulud 2.0 mit einem gründlichen Durchleuchten der Umgebung. Der Wurm nutzt u.a. das Open-Source-Tool TruffleHog und sucht nach: [Technische Analyse]

• Lokale Konfigurationsdateien: AWS-Credentials in ~/.aws/credentials, GCP Default Credentials, Azure-Creds, SSH-Schlüssel, .npmrc-Tokens
• Umgebungsvariablen: Alle in process.env enthaltenen Werte – CI-Systeme setzen hier oft API-Keys und DB-Passwörter
• Cloud-Metadaten: Temporäre Anmelde-Token von AWS, Azure und GCP Instanz-Metadata-Services
• Secrets-Manager: Direkte Abfrage von AWS Secrets Manager, Azure Key Vault, GCP Secret Manager

3.2 Cross-Victim-Exfiltration

Besonders perfide: Falls der Wurm auf einem System keine GitHub-Credentials findet, sucht er auf GitHub nach bereits existierenden Shai-Hulud-Repos anderer Opfer und nutzt dort hinterlegte Tokens, um eigene Daten hochzuladen. Ein einzelner GitHub-Account kann so Daten mehrerer Opfer enthalten. [Technische Analyse]

4. Ausmaß und Risiko für Organisationen

Warum gilt Shai-Hulud 2.0 als der bisher aggressivste npm-Supply-Chain-Angriff? Die Zahlen sprechen für sich: [Analyse]

4.1 Betroffene Bereiche

Die betroffenen Pakete deckten ein weites Feld ab – von Krypto-Libraries über Workflow-Automatisierungs-Tools bis zu Frontend- und Backend-Komponenten. Darunter befanden sich auch Libraries von: [Incident Report]

• Zapier – Workflow-Automatisierung
• ENS Domains – Ethereum Name Service
• PostHog – Product Analytics
• Postman – API-Entwicklung

4.2 Realistische Impacts

Was kann ein Angreifer mit den erlangten Geheimnissen anstellen?

5. Incident-Response-Checkliste

Falls Sie (vielleicht unwissentlich) von Shai-Hulud 2.0 betroffen sind oder es nicht sicher ausschließen können, hier ist eine pragmatische Checkliste: [Threat Intelligence]

1. Betroffene Pakete identifizieren:
   • Prüfen Sie package-lock.json, yarn.lock oder pnpm-lock.yaml
   • Suchen Sie nach Versionen, die zwischen 21. und 24. November 2025 veröffentlicht wurden
   • Nutzen Sie SBOM- oder Dependency-Scanner für indirekte Abhängigkeiten
   • Prüfen Sie auch CI-Logs und npm-Cache
2. Umfang abgrenzen:
   • Entwicklerrechner, CI-Agenten, Build-Server, Docker-Build-Images
   • Der Wurm konnte sich auch in Docker-Containern ausführen
3. Credential Rotation durchführen:
   • npm-Tokens – alle Publishing-Token widerrufen
   • GitHub-Zugangsdaten – PATs, App-Tokens, Passwörter
   • CI/CD-Systemschlüssel – Jenkins, GitHub Actions, GitLab CI
   • Cloud-Provider Keys – AWS, Azure, GCP Access Keys
   • SSH-Schlüssel, DB-Passwörter, API-Schlüssel
4. Backdoors in GitHub & CI bereinigen:
   • Suchen Sie nach Repos mit Beschreibung "Sha1-Hulud: The Second Coming."
   • Prüfen Sie .github/workflows/ auf unbekannte YAML-Dateien
   • Löschen Sie unbekannte selbstgehostete GitHub Runners
   • Leeren Sie den npm-Cache auf betroffenen Maschinen
5. Logs analysieren:
   • GitHub Audit Logs auf ungewöhnliche Events (21.–27. Nov.)
   • CI/CD-Logs auf Base64-Strings oder bun-Installationen
   • Cloud-Monitoring (CloudTrail, Audit Logs) auf verdächtige Zugriffe
6. Kommunikation & Reporting:
   • Security-Team, Management und relevante Dev-Teams informieren
   • DSGVO-Meldepflicht prüfen bei möglichem Kundendatenabfluss
   • Bei Bedarf externe Incident-Response-Experten hinzuziehen

6. Präventionsmaßnahmen & Best Practices

Die gute Nachricht: Man braucht kein High-End-Security-Setup, um das Risiko solcher Supply-Chain-Angriffe drastisch zu senken. Viele effektive Maßnahmen sind einfacher Grundschutz:

6.1 Token- & Credential-Hygiene

• Minimalberechtigung und kurze Gültigkeit: Tokens nur mit geringstmöglichen Rechten, automatische Expiration (npm: 7 Tage default, GitHub PATs: max 90 Tage) [Security Advisory]
• Kein Hardcoding: Nutzen Sie Secret-Management-Lösungen (Vault, Cloud Secret Manager)
• MFA überall: GitHub und npm machen MFA zur Pflicht für Publisher – nutzen Sie FIDO2-Keys statt SMS/OTP
• OIDC-basiertes Trusted Publishing: Veröffentlichen Sie npm-Pakete ohne statische Tokens via OpenID Connect aus CI/CD heraus

6.2 npm & CI/CD härten

• Lifecycle-Skripte deaktivieren: npm ci --ignore-scripts in CI-Umgebungen – Shai-Hulud wäre ohne automatisches preinstall nie zur Ausführung gekommen
• Lockfiles strikt nutzen: Immer npm ci statt npm install, Review-Prozess für Lockfile-Änderungen
• Dependency-Scanning: SBOM, SCA-Tools, Malware-Scanner in der Pipeline
• Secret-Scanning aktivieren: GitHub Advanced Security oder ähnliche Tools

6.3 GitHub-Sicherheit

• GitHub Actions absichern: Nur Verified Actions erlauben, Branch Protection, Reviews für Workflow-Änderungen
• Monitoring einrichten: Alerts für neue Repos, neue Org-Mitglieder, neue Runner
• Secrets isolieren: Build-Schritte ohne Zugriff auf Prod-Secrets, Protected Variables nutzen

7. Code- & Konfigurationsbeispiele

Hier sind konkrete Beispiele, wie Sie zwei zentrale Lessons aus Shai-Hulud 2.0 direkt umsetzen können:

# npm mit deaktivierten Lifecycle-Skripten (empfohlen für CI)
npm ci --ignore-scripts

# Alternativ für yarn/pnpm:
yarn install --ignore-scripts --frozen-lockfile
pnpm install --ignore-scripts --frozen-lockfile

# Globale Deaktivierung in .npmrc (für CI-Server):
echo "ignore-scripts=true" >> ~/.npmrc

# .github/workflows/publish.yml
name: Publish package

on:
  push:
    tags:
      - "v*.*.*"

permissions:
  contents: read
  id-token: write   # wichtig für OIDC-basierte Authentifizierung

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org'
      
      # OIDC-basierte npm-Authentifizierung - KEIN statisches Token nötig!
      - run: npm ci --ignore-scripts
      - run: npm publish --provenance --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}  # Oder besser: OIDC

# Nach Shai-Hulud-Repos im eigenen Account suchen
gh repo list --json name,description | \
  jq '.[] | select(.description | contains("Sha1-Hulud"))'

# Verdächtige Workflow-Dateien finden
find . -path "*/.github/workflows/*.yml" -newer "2025-11-20" -exec ls -la {} \;

# Unbekannte GitHub Runners auflisten
gh api /repos/OWNER/REPO/actions/runners | jq '.runners[] | {name, status}'

# npm-Cache leeren (auf betroffenen Systemen)
npm cache clean --force
rm -rf ~/.npm/_cacache

8. Lessons Learned für Entscheider

Was sollten CTOs, Engineering Manager und alle, die Verantwortung für Softwareprojekte tragen, aus Shai-Hulud 2.0 mitnehmen?

„Die Kampagne zeigt, wie leicht ein Angriff auf der Dependency-Ebene zu umfassendem Multi-Cloud-Zugriff, langfristiger Entwicklerkonto-Kompromittierung und weitreichender CI/CD-Infiltration eskalieren kann."
Quelle: Check Point Research [Analyse]

1. Supply-Chain-Security ist Kernaufgabe: Nach SolarWinds (2020), CodeCov (2021) und Shai-Hulud (2025) gehört die Absicherung der Software Supply Chain ganz oben auf die Agenda.
2. Token-Hygiene ist effektiver Hebel: Kurze, streng limitierte Tokens, konsequente 2FA, keine Hardcoded Secrets – das nimmt einem ganzen Angriffsmodus den Wind aus den Segeln.
3. Automatisierung braucht Team-Kultur: Tools helfen nur, wenn sie richtig eingebettet sind. Menschliche Wachsamkeit bleibt essentiell.
4. Vom Paket- zum Ökosystem-Angriff: Shai-Hulud 2.0 hat das gesamte npm/GitHub-Ökosystem als Botnetz verwendet – Sicherheit muss holistisch gedacht werden.
5. Grundschutz zahlt sich aus: Organisationen mit den genannten Maßnahmen waren nachweislich deutlich besser aufgestellt.

9. Häufige Fragen

Wie erkenne ich, ob mein Projekt betroffen ist?

Prüfen Sie Ihre Lockfiles (package-lock.json, yarn.lock) auf Paketversionen, die zwischen dem 21. und 24. November 2025 veröffentlicht wurden. Suchen Sie nach den Dateien setup_bun.js und bun_environment.js in Ihren node_modules. Nutzen Sie Tools wie npm audit oder SBOM-Scanner.

Reicht es, die betroffenen Pakete zu aktualisieren?

Nein. Wenn ein infiziertes Paket jemals installiert wurde, müssen Sie davon ausgehen, dass alle Secrets auf diesem System kompromittiert sind. Credential Rotation ist zwingend erforderlich. Außerdem sollten Sie nach persistenten Backdoors (GitHub Runners, Workflows) suchen.

Warum nutzt der Wurm Bun statt Node.js?

Bun ist eine alternative JavaScript-Laufzeit, die deutlich weniger verbreitet ist als Node.js. Viele Security-Tools überwachen speziell Node-Prozesse – durch Bun umgeht der Wurm diese Überwachung und läuft „unter dem Radar".

Wie kann Six Eight Consulting helfen?

Wir unterstützen bei der Analyse Ihrer CI/CD-Pipelines und Dependency-Management-Prozesse. Von Quick-Wins wie Token-Hygiene-Policies bis zur Einführung von DevSecOps-Standards – immer mit dem Fokus auf pragmatische Lösungen, die zu Ihrem Unternehmenskontext passen. Sprechen Sie uns an.

Wenn Sie die Grundlagen der IT-Security zuerst festigen möchten, empfehlen wir Ihnen den Beitrag „IT-Security-Grundlagen für kleine Unternehmen" . Weitere Fachartikel finden Sie im Bereich Supply-Chain- und Cloud-Security .