Der Angriff auf die npm-Lieferkette traf am 4. August 2026 das GitHub-Konto des Maintainers hinter keyv, einem Paket mit 619 Millionen Downloads pro Monat. Binnen Stunden sprang der Wurm auf 868 weitere Pakete über. Die vergifteten Versionen landeten mit einer gültigen, von GitHub Actions signierten Provenance auf npm.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Zwei Milliarden Installationen pro Monat hängen an den Paketen, die dieser Angriff auf die npm-Lieferkette erreicht hat.[1] Betroffen sind keyv, flat-cache, file-entry-cache und cacheable-request, also Bausteine, die kaum ein Node.js-Projekt bewusst auswählt und fast jedes mitschleppt. Der Schadcode startet bereits beim Installieren, lange bevor jemand die Anwendung ausführt.
Das Wichtigste in Kürze
- Der Wurm erreichte nach der Analyse von Aikido Security 868 Pakete in 1.381 Versionen mit zusammen über zwei Milliarden Installationen pro Monat.
- Die Schadversionen erschienen mit gültiger, von GitHub Actions signierter Provenance auf npm.
- Ein preinstall-Hook lädt die Bun-Runtime nach, danach sammelt der Schadcode npm-, GitHub-, AWS- sowie Vault-Zugangsdaten ein.
- Ab dem 11. September 2026 verlangt der Cyber Resilience Act eine Erstmeldung binnen 24 Stunden.
Wie kam der Schadcode in die Pakete?
Der Weg führte über das GitHub-Konto des Maintainers, nicht über einen gestohlenen npm-Token. Die Angreifer schoben zwei Dateien direkt auf den main-Branch und schnitten sofort danach ein neues Release.[1] Die Veröffentlichung auf npm übernahm anschließend die echte Release-Pipeline des Projekts.
Der Einstiegspunkt heißt setup.mjs und hängt als preinstall-Hook am Paket. Der Dropper lädt die JavaScript-Laufzeit Bun von GitHub nach und startet damit eine 728 Kilobyte große, verschleierte Datei namens Math_Symbol.js. Danach durchsucht der Schadcode .npmrc, GitHub-Token, AWS-Schlüssel sowie Vault-Token. Verschlüsselt landet die Beute in einem Repository der Angreifer.[1]
Warum schützt die gültige Signatur nicht?
Eine npm-Provenance belegt, wo ein Paket gebaut wurde, und nicht, dass der Inhalt harmlos ist. Die npm-Dokumentation formuliert das ausdrücklich: Die Provenance liefert eine überprüfbare Verbindung zum Quellcode und zur Build-Anweisung, mehr nicht.[3] Sobald ein Angreifer Schreibrechte im Repository besitzt, signiert die legitime Pipeline seinen Code mit.
Wiz Research ordnet den Schadcode der Familie Mini Shai-Hulud zu, die schon hinter den Kampagnen gegen TeamPCP und AntV stand.[2] Nach derselben Mechanik umging im Mai ein Wurm die SLSA-Provenance von 42 TanStack-Paketen. Im Juni traf die Welle die npm-Pakete von Red Hat, danach stahl der Miasma-Wurm Zugänge zu Cloud-Konten.
Die Provenance-Signatur auf npm beweist, aus welchem Repository ein Paket stammt, und sonst gar nichts. Solange ein preinstall-Hook beim Installieren fremden Code startet, hilft die sauberste Signatur keinem Betreiber.
— Markus Seyfferth, Chefredakteur Dr. Web
So lief der Angriff
Was müssen Unternehmen im DACH-Raum jetzt tun?
Ab dem 11. September 2026 verlangt der Cyber Resilience Act eine Erstmeldung binnen 24 Stunden, sobald eine aktiv ausgenutzte Schwachstelle im eigenen Produkt steckt. Das BSI nennt diese Frist ausdrücklich, ein ausführlicher Bericht folgt nach 72 Stunden.[4] Hersteller, die keyv über eine Abhängigkeitskette in ihr Produkt einbauen, tragen diese Meldepflicht selbst. Zur Pflicht gehört auch eine Stückliste aller verwendeten Softwarekomponenten, die sogenannte SBOM.
Für die kommenden Tage zählt allerdings die Aufräumarbeit. Vier Schritte gehören sofort auf den Tisch:
- Jede Installation der letzten 48 Stunden als kompromittiert behandeln und das Lockfile gegen die Versionsliste von Wiz Research abgleichen.
- npm-Token, GitHub-Token, AWS-Schlüssel sowie Vault-Zugänge rotieren, dazu die Secrets der betroffenen CI-Umgebungen.
- Lifecycle-Skripte in der Build-Pipeline mit der Option –ignore-scripts abschalten und nur für geprüfte Pakete wieder freigeben.
- Eine Wartezeit für frische Versionen setzen, wie GitHub sie bei Dependabot auf drei Tage voreingestellt hat.
Die Zuständigkeit für diese Entscheidungen liegt nicht im Entwicklerteam, sondern in der Geschäftsführung, wie unser Beitrag zu Cybersecurity als Chefsache zeigt. Prüfen Sie heute, welche Ihrer Produkte Node.js-Pakete ausliefern, und legen Sie fest, wer die 24-Stunden-Meldung absetzt.
FAQ: Keyv kompromittiert, der Angriff auf die npm-Lieferkette läuft noch
Welche npm-Pakete sind vom Angriff betroffen?
Betroffen sind keyv, cacheable, cacheable-request, flat-cache, file-entry-cache, cache-manager, ecto sowie die Pakete unter dem Namensraum @cacheable. Über den Wurm kamen bis zum 4. August 2026 rund 868 weitere Pakete in 1.381 Versionen dazu, darunter Pakete von @ornikar und @qlik.
Woran erkenne ich, dass mein Projekt betroffen ist?
Suchen Sie im Projektverzeichnis nach den Dateien setup.mjs und Math_Symbol.js sowie nach einem preinstall-Eintrag in der package.json einer Abhängigkeit. Prüfen Sie zusätzlich das Lockfile auf Versionen, die zwischen dem 3. und 5. August 2026 installiert wurden.
Schützt npm audit vor solchen Angriffen?
Nein. Der Befehl npm audit vergleicht installierte Versionen mit bekannten Schwachstellen-Datenbanken. Frisch veröffentlichter Schadcode steht dort noch nicht drin, deshalb meldet npm audit bei einem laufenden Lieferketten-Angriff in aller Regel nichts.
Was bedeutet Provenance bei npm-Paketen?
Provenance ist ein signierter Nachweis darüber, aus welchem Repository und aus welchem Build-Lauf ein Paket stammt. Die Signatur bestätigt die Herkunft, prüft aber nicht, ob der veröffentlichte Code harmlos ist.
Welche Zugangsdaten muss ich nach einem Treffer wechseln?
Wechseln Sie npm-Token, GitHub-Token samt OAuth-Sitzungen, AWS-Schlüssel, HashiCorp-Vault-Token sowie alle Secrets aus den betroffenen CI-Umgebungen. Auch SSH-Schlüssel und Kubernetes-Zugänge auf den betroffenen Rechnern gehören dazu.
Quellen
[1] Aikido Security: „Keyv and friends compromised in npm supply chain attack“
[2] Wiz Research: „keyv and cacheable npm Package Hijacked in Supply Chain Attack“
[3] npm Docs: „Generating provenance statements“
[4] BSI: „Cyber Resilience Act“
Mehr Newshunger?
- PyPI blockiert neue Dateien in alten Releases nach 14 Tagen
- npm zwingt zur 2FA: Stage-Queue stoppt gestohlene CI-Tokens
- TrapDoor: 34 Pakete plündern Wallets, Tokens und KI-Assistenten
- 30 manipulierte npm-Pakete: Red Hats Lieferkette unter Beschuss
- Wird Homebrew 6.0 endlich sicherer dank Tap Trust?
- Jeder vierzehnte MCP-Server fällt durch
