LONDON (IT BOLTWISE) – Ein credential-stealing NPM-Wurm startete mit [email protected] und streute sich am 4. August 2026 in Hunderte von Paketen über mehrere Organisationen. Laut SafeDep wurden zunächst 353 vergiftete Versionen über 79 Paketnamen verifiziert, später die Zahl auf 1.684 vergiftete Versionen in 420 Paketnamen erhöht. Die Kompromittierung nutzt einen preinstall-Baustein, der aus Build- und CI-Umgebungen heraus Credentials und Schlüsselmaterial abgreifen kann. Zusätzlich existieren im Keyv-Repository separate Ausführungswege über Claude- und VS-Code-Hooks, die bei geöffneten Projekten je nach Vertrauenseinstellung das Payload-Handling triggern können.

Der Vorfall wirkt auf den ersten Blick wie eine typische Supply-Chain-Geschichte, ist aber technisch deutlich vielseitiger: Der Wurm, der in [email protected] erstmals auftauchte, setzt nicht nur auf einen kompromittierten Paketinhalt, sondern kombiniert einen preinstall-Ausführungsweg mit zusätzlichen Hook-Pfaden aus dem Entwickler-Tooling. Die Ausnutzung passiert damit dort, wo viele Build-Prozesse bereits privilegierten Zugriff auf Token und Publishing-Rechte haben – nämlich in lokalen Installationsläufen und in CI/Automationen. Genau dadurch ist die Schadenslogik gefährlich: Selbst wenn nur ein einzelnes Abhängigkeits-Update in eine Pipeline gelangt, können die Folgen als Credential-Abfluss und als weiteres Vergiften von Paketen in der NPM-Registry weiterlaufen.
Die Größenordnung wird in den öffentlich beschriebenen Analysen über Versions- und Paketnamen-Counts eingeordnet. SafeDep hatte zum frühen Zeitpunkt 353 vergiftete Versionen über 79 Paketnamen in der Registry verifiziert und später, nach einer erweiterten Zählung, 1.684 vergiftete Versionen in 420 Paketnamen mit Bezug auf neun Organisationen gemeldet. Aikido nannte zunächst noch deutlich höhere Paketnamen-Werte, blieb aber bei den Versionen niedriger; entscheidend ist: Beide Zahlen meinen maliziöse Paketartefakte, nicht die Anzahl betroffener Systeme. Dadurch lassen sich aus den Aggregaten keine direkten Aussagen über die real installierten oder ausgeführten Payload-Instanzen ableiten. Genau diese Lücke müssen Teams schließen, indem sie die bei ihnen aufgelösten Abhängigkeitsversionen, konkrete Lockfiles und das tatsächliche Ausführungsverhalten der Lifecycle-Skripte prüfen.
Technisch folgt der Angriff einem klaren Muster, das in NPM-Umgebungen besonders gut funktioniert: In dem von keyv ausgelieferten Setup-Skript wird vor der eigentlichen Paketinstallation ein zusätzlicher Bundle-Schritt ausgeführt, der in diesem Fall auch über die Build-/Runner-Kontexte Daten einsammelt. SafeDep beschreibt, dass der Payload u. a. GitHub-, NPM-, Cloud-, Vault-, Kubernetes-, Datenbank- und private-key-nahe Informationen harvesten kann und zudem einen „token-revocation watcher“ installiert. Die Idee dahinter ist nicht nur „Daten stehlen“, sondern auch „Zeitpunkt steuern“: Die Watcher-Logik soll als Trigger dienen, um später eine gefasste Token-/Key-Revocation auszunutzen. Für Incident-Responder ist daraus ein konkreter Ablauf relevant: SafeDep rät ausdrücklich dazu, den Credential-revocation-Watcher zu entfernen, bevor exponierte Tokens und Keys rotiert werden. Hintergrund ist ein klassisches Angriffsrennen im Prozess: Rotieren „zuerst“ kann dazu führen, dass der Angreifer einen lokalen Handler in der Umgebung noch rechtzeitig anspringen lässt.
Ein weiterer Schwerpunkt liegt auf der Frage, wie der Payload außerhalb reiner Paket-Installationen wirksam wird. Zusätzlich zur preinstall-Kette existiert im Repository ein separater Ausführungsweg über IDE-/Agent-Integrationen. Im Keyv-Repo finden sich Angaben zufolge eine Claude-Code-Konfiguration in .claude/settings.json mit einem SessionStart-Hook, der .vscode/setup.mjs aufruft. Außerdem enthält .vscode/tasks.json eine Environment-Setup-Task, die bei „runOn: folderOpen“ .claude/setup.mjs ausführt. Diese Route ist nicht zwangsläufig bei jedem Entwicklerfall „autorisierend“ aktiv, sondern hängt von Vertrauens- und Sicherheitsmechanismen ab: VS Code blockiert automatische Tasks in nicht vertrauenswürdigen Workspaces und fragt in vielen Default-Szenarien nach; Claude Code wiederum ordnet Workspace-Trust Projektkonfigurationen aus dem Repository zu. Damit verschiebt sich die Risikoabschätzung: Neben „hat NPM diese Version installiert?“ kommt „wurde ein betroffenes Repo in einer vertrauenswürdigen Entwicklungsumgebung geöffnet, und haben die Hook-Bedingungen gepasst?“ als eigenständige Prüfdimension hinzu.
Für die Frage, warum solche Angriffe trotz moderner Supply-Chain-Sicherheitsbemühungen funktionieren, ist die in den Attestations sichtbar werdende Legitimität wichtig – und zugleich trügerisch. Der poisoned Keyv-Release habe eine gültige OpenID-Connect- und SLSA-Provenance-Information getragen, weil der Build über den etablierten GitHub-Actions-Workflow des Projekts lief. Eine passende Attestation bestätigt damit vor allem: „So wurde das Artefakt technisch gebaut und signiert“, nicht: „Die einliefernde Quelle war frei von Schadcode“. SafeDep beschreibt außerdem, dass der gleiche Payload unter direkten NPM-Publishing-Accounts in anderen Teilen der Kampagne auftauchte. Das legt nahe, dass automatisierte Propagation über Publishing-Zugriff eine Rolle gespielt hat – ob das Ganze aber aus einem einzigen gestohlenen Publishing-Identitätskonto heraus geschah oder auch durch separat kompromittierte Publisher-Credentials, bleibt in der Auswertung offen. Ebenso gilt: Die Repository-Historie zeigt signierte Commit-Pfade und einen verifizierten Badge für den Commit; daraus folgt nur, dass die Signaturkette intakt war, nicht wer die dazugehörige Credential tatsächlich kontrollierte.
Besonders praxisnah ist die Beobachtung, dass npm 12 unapproved lifecycle scripts standardmäßig blockiert, während ältere NPM-Clients und Installpfade, die Lifecycle-Skripte erlauben, weiterhin angreifbar bleiben. In der Praxis heißt das: „Update auf neuere Version“ reduziert nicht automatisch alle Risiken, wenn bereits betroffene Pakete in bestehenden Lockfiles fest verdrahtet sind oder wenn ein Installationspfad im Unternehmen (oder ein CI-Image) Lifecycle-Skripte noch zulässt. Dazu kommt, dass die Registry-„latest“-Tags zur Laufzeit nicht zuverlässig als Prüfinstanz taugen: SafeDep berichtet, dass die NPM-Paketseiten gegen 5:40 p.m. IST frühere Releases zeitweise wieder als latest auswiesen. Folgerichtig empfehlen die Forscher Checks über exakt aufgelöste Paketnamen und -versionen inklusive Lockfile-Resolutions statt über „was steht aktuell auf latest“.
Der nächste Handlungsblock betrifft damit direkt die Ermittlungslogik im Unternehmen. Da Upgrading allein exponierte Pfade nicht zwingend eliminiert, sollten Teams Abhängigkeitsbäume gegen die betroffenen Paketlisten und insbesondere gegen die „poisoned“-Versionen abgleichen, Lockfiles vergleichen und unnötige Install-Skripte in ihren Build-Systemen deaktivieren. Parallel gilt: Jede Umgebung, die eine betroffene Version ausgeführt hat, muss als credential-exponiert behandelt werden. SafeDep nennt zudem konkrete Repository-Spuren: In einem Update nach der ersten Zählung seien die .claude– und .vscode-Verzeichnisse auf main weiterhin enthalten gewesen, einschließlich der Dateien, die den IDE-basierten Ausführungsweg beschreiben. Auch wenn SafeDep bestimmte Keyv- und Cacheable-Releases zwischenzeitlich wieder entpubliziert haben soll, können „latest“-Auflösungen zu dem Zeitpunkt weiterhin auf kompromittierte Versionen zeigen – wodurch ein reines „npm install“ ohne Lockfile-Disziplin erneut Risiko erzeugt.
Als zusätzlicher Indikator für die Kontinuität der Kampagne gilt, dass Aikido die August-Aktivität in eine Malware-Familie namens Shai-Hulud einordnet und dabei eine Überlappung zu einem früheren April-Komproment auf einem Lightning-PyPI-Paket erwähnt. Diese Zuordnung stützt die Vermutung einer ähnlichen Familienlogik, klärt aber nicht, wer im August operiert hat. Der offene Punkt bleibt: Der initiale Zugriffspfad ist nicht vollständig rekonstruiert, und es ist nicht eindeutig, ob ein einzelnes gestohlenes Publisher-Konto die gesamte Propagation trug oder mehrere Identitäten genutzt wurden. Genau deshalb sollte die Sicherheitsreaktion nicht nur als „Paket ersetzen“ verstanden werden, sondern als Kombination aus Artefaktprüfung, exakter Versionsverifikation und hardening der Install- und Entwicklungsumgebung – inklusive der Frage, welche IDE-Integrationen „Workspace Trust“ tatsächlich ausnutzen dürfen.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!

- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Keyv-NPM-Wurm: Preinstall-Skripte kompromittieren Hunderte Pakete und IDE-Hooks" für unsere Leser?


#Sophos
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Keyv-NPM-Wurm: Preinstall-Skripte kompromittieren Hunderte Pakete und IDE-Hooks" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Keyv-NPM-Wurm: Preinstall-Skripte kompromittieren Hunderte Pakete und IDE-Hooks« bei Google Deutschland suchen, bei Bing oder Google News!