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.

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.

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.

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.

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.

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. 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$.

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:

• 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.

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:

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:

• 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.

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.

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:

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:

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

Realistische Impacts

Was kann ein Angreifer mit den erlangten Geheimnissen anstellen?

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:

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.

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:

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).
• 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.

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.

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.

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

Lessons Learned für Entscheider

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

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.

Häufige Fragen