Forscher melden eine großangelegte Kompromittierung von mehr als 180 npm-Paketen durch eine selbstreplizierende Malware, die abhängige Projekte automatisch trojanisiert und aktiv nach Geheimnissen wie Tokens und Schlüsseln sucht. Die Kampagne trägt den Namen Shai-Hulud nach einer von Angreifern angelegten Workflow-Datei shai-hulud.yaml in Ziel-Repositorys. Betroffen waren unter anderem Pakete im Account von CrowdStrike; das Unternehmen erklärte, es bestehe keine Gefahr für Falcon oder Kunden, verdächtige Veröffentlichungen seien entfernt und Schlüssel rotiert.
Supply-Chain-Angriff auf npm: Ausmaß und Erste Hinweise
Der Vorfall wurde zunächst vom Entwickler Daniel Pereira bemerkt, der vor neuen Versionen von @ctrl/tinycolor (über 2 Mio. Downloads pro Woche) warnte. Teams von Socket und Aikido bestätigten im Zuge der Analyse mindestens 187 kompromittierte Pakete. ReversingLabs spricht von einem „erstmals beobachteten“ Wurm-artigen Verhalten im npm-Kontext, der vor allem auf die Entwendung von Cloud-Tokens abzielt. Als möglicher Ausgangspunkt gilt das Paket rxnt-authentication (bösartige Version vom 14. September 2025), verknüpft mit dem Account techsupportrxnt, der mutmaßlich über Phishing oder eine verwundbare GitHub Action kompromittiert wurde.
Taktiken, Techniken, Verfahren: So verbreitet sich Shai-Hulud
Die Malware integriert Selbstverbreitung in kontaminierte Versionen: Sie lädt sämtliche Pakete eines Maintainers, modifiziert die package.json, fügt einen bundle.js-Skripthook hinzu, verpackt neu und veröffentlicht eine weitere Version. Dadurch werden nachgelagerte Abhängigkeiten im Ökosystem automatisiert trojanisiert.
Missbrauch von GitHub Actions und systematische Geheimnisjagd
In kompromittierten Repos legt der Wurm den Workflow shai-hulud.yaml an und nutzt den legitimen Scanner TruffleHog, um Tokens, Passwörter und Cloud-Schlüssel aufzuspüren. Gefundene Secrets werden validiert und zur weiteren Ausbreitung verwendet. Die Exfiltration erfolgt an einen hartkodierten Webhook https://webhook[.]site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7. Zusätzlich versuchen die Angreifer, öffentliche Klone privater Repositories mit dem Präfix „migration“ zu erzeugen, um Quellcode und eingebettete Secrets abzuschöpfen.
Bewertung des Risikos und mögliche Zusammenhänge
Wegen der dichten Abhängigkeitsnetze im npm-Ökosystem ist die Reichweite der Kaskadeneffekte schwer vorherzusagen. Forscher sehen Parallelen zur jüngsten Supply-Chain-Kampagne s1ngularity, in deren Verlauf tausende Repositories und Accounts offengelegt wurden. Aktuell sprechen Analysen von „Hunderten“ kontaminierter Pakete; Registry-Betreiber und Sicherheitsanbieter entfernen fortlaufend bösartige Veröffentlichungen.
Indikatoren der Kompromittierung (IoCs) und Detektionshinweise
IoCs: Auftauchen von .github/workflows/shai-hulud.yaml; injizierter bundle.js; untypische package.json-Skripte (postinstall/prepare); öffentliche „migration“-Forks ehemaliger Privat-Repos; Netzwerkverkehr zu webhook[.]site; TruffleHog-Aufrufe im CI.
Praktische Abwehr: Maßnahmen für Maintainer und Entwicklungsteams
Maintainer sollten sofort Tokens für npm/GitHub/Cloud rotieren, kompromittierte Versionen yanken und sauber neu veröffentlichen, verdächtige GitHub Actions entfernen, 2FA aktivieren und Token-Rechte strikt nach dem Least-Privilege-Prinzip beschränken. Blockieren Sie Actions aus Forks, pinnen Sie Actions per SHA, aktivieren Sie Secret-Scanning und Branch-Protection und prüfen Sie Audit-Logs sowie npm-Publish-Historien.
Entwicklungsteams sollten Abhängigkeiten fixieren (lockfiles), reproduzierbare Builds via npm ci nutzen und, wo möglich, Installationsskripte temporär mit –ignore-scripts deaktivieren. Überwachen Sie Build-Zeit-Netzwerkverkehr, setzen Sie Allowlists für kritische CI-Umgebungen und nutzen Sie Supply-Chain-Analysen (z. B. Socket, Aikido, ReversingLabs). Ergänzend hilfreich: signierte Provenance/Attestierungen, SLSA-orientierte Build-Kontrollen und schreibgeschützte GITHUB_TOKEN-Policies in Workflows.
Der Fall Shai-Hulud unterstreicht, wie eine einzelne Kompromittierung eines Maintainers oder der CI/CD-Kette zu einer Ketteninfektion in großen Ökosystemen führen kann. Organisationen sollten ihre Lieferkette mehrschichtig absichern: rigorose Geheimnishygiene, minimale Berechtigungen, harte CI-Isolation, Version-Pinning und konsequente Verifikation von Drittcode. Prüfen Sie zeitnah die genannten IoCs, rekonstruieren Sie Artefakte aus vertrauenswürdigen Quellen und etablieren Sie Prozessdisziplin, um laterale Ausbreitung in Build-Pipelines nachhaltig zu verhindern.
