npm unter Beschuss: chalk, debug und der Wurm Shai-Hulud
Innerhalb einer Woche wurde das npm-Ökosystem gleich zweimal schwer getroffen: erst durch gekaperte Pakete wie chalk und debug, dann durch den selbstverbreitenden Wurm Shai-Hulud. Lockfiles, gepinnte Abhängigkeiten, eine SBOM und regelmäßig rotierte CI-Secrets sind damit endgültig Pflicht für jedes Webprojekt.
Was ist passiert?
Angriff 1: chalk und debug. Am 8. September 2025 übernahmen Angreifer das npm-Konto eines bekannten Maintainers. Der Weg dorthin war klassisches Phishing: Eine angebliche Aufforderung zum Zurücksetzen der Zwei-Faktor-Authentifizierung kam von der Domain npmjs.help, die laut Aikido erst drei Tage zuvor registriert worden war. Anschließend veröffentlichten die Angreifer manipulierte Versionen von 18 Paketen, darunter debug mit rund 358 Millionen und chalk mit rund 300 Millionen wöchentlichen Downloads. Zusammen kommen die betroffenen Pakete auf mehr als zwei Milliarden Downloads pro Woche.
Der Schadcode zielte auf Webanwendungen im Browser: Er klinkte sich in Netzwerkfunktionen und Wallet-Schnittstellen ein und tauschte Empfängeradressen von Kryptowährungs-Transaktionen gegen Adressen der Angreifer aus. Laut Berichten waren die manipulierten Versionen nur rund zwei Stunden verfügbar, bevor sie entfernt wurden. Wer in diesem Zeitfenster Abhängigkeiten aktualisiert und ausgeliefert hat, sollte trotzdem genau prüfen.
Angriff 2: Shai-Hulud. Ab dem 15. September tauchten weitere manipulierte Pakete auf, darunter @ctrl/tinycolor und Pakete von CrowdStrike. Diesmal ging es um Zugangsdaten. Beim Installieren startet ein postinstall-Skript, das mit dem Werkzeug TruffleHog nach Secrets sucht, darunter GitHub- und npm-Tokens sowie Cloud-Schlüssel. Gefundene Daten landen in öffentlichen GitHub-Repositories mit dem Namen „Shai-Hulud“. Zusätzlich legt die Malware GitHub-Actions-Workflows an, die Secrets abfließen lassen, und macht private Repositories öffentlich. Findet sie npm-Tokens, veröffentlicht sie infizierte Versionen weiterer Pakete des betroffenen Maintainers. So verbreitet sie sich selbstständig wie ein Wurm. Sicherheitsforscher zählten bis zum 16. September bereits mehr als 180 kompromittierte Pakete, Tendenz steigend.
So verbreitet sich Shai-Hulud:
Warum betrifft Sie das?
Fast jedes moderne Webprojekt, ob Nuxt, React, Vue oder ein Node-Backend, zieht hunderte bis tausende npm-Pakete nach. Pakete wie chalk oder debug stecken als indirekte Abhängigkeit in nahezu jedem Projekt, oft ohne dass das Team sie bewusst eingebunden hat. Besonders gefährlich ist Shai-Hulud für Build-Server: CI/CD-Pipelines verfügen typischerweise über Tokens für Registries, Cloud-Konten und Repositories. Ein einziges npm install mit der falschen Version kann genügen, um diese Zugänge preiszugeben.
Was Sie jetzt tun sollten
- Betroffenheit prüfen: Gleichen Sie Ihre Lockfiles mit den veröffentlichten Listen kompromittierter Versionen ab, zum Beispiel so:
npm ls chalk debug ansi-styles supports-color --all
grep -n "tinycolor" package-lock.json
- Lockfiles konsequent nutzen: Committen Sie
package-lock.json,pnpm-lock.yamloderyarn.lockund installieren Sie in CI ausschließlich mitnpm cistattnpm install. - Abhängigkeiten pinnen: Verzichten Sie bei kritischen Projekten auf breite Versionsbereiche und aktualisieren Sie gezielt, etwa über Renovate oder Dependabot mit Review.
- Install-Skripte einschränken: Prüfen Sie, ob Sie
postinstall-Skripte in CI deaktivieren können (npm ci --ignore-scripts), und erlauben Sie sie nur dort, wo sie wirklich nötig sind. - SBOM erstellen: Eine Software-Stückliste zeigt im Ernstfall in Minuten, welche Anwendungen betroffen sind:
npm sbom --sbom-format cyclonedx > sbom.json
- Secrets rotieren: Wenn betroffene Versionen installiert wurden, gelten alle erreichbaren Tokens als kompromittiert. Erneuern Sie npm-, GitHub- und Cloud-Zugänge und prüfen Sie Ihre GitHub-Organisation auf Repositories namens „Shai-Hulud“ und unbekannte Workflows.
- Tokens minimieren: Nutzen Sie kurzlebige, fein granulierte Tokens und OIDC statt dauerhafter Schlüssel in CI.
- Phishing-resistente MFA: Setzen Sie für Entwickler- und Registry-Konten auf Hardware-Schlüssel oder Passkeys statt auf Einmalcodes.
Fazit
Die Angriffe zeigen, dass Lieferketten-Sicherheit kein Thema nur für Konzerne ist. Jedes Projekt mit npm-Abhängigkeiten ist Teil dieser Kette. Die gute Nachricht: Die wirksamsten Gegenmaßnahmen sind bekannt und mit überschaubarem Aufwand umsetzbar, von sauberen Lockfiles bis zu abgesicherten Pipelines. Wenn Sie Ihre Webprojekte und CI/CD-Prozesse darauf prüfen lassen möchten, sprechen Sie uns an.