---
service: "Publicasta"
schema_version: "1.0"
article_id: 290
title: "Wenn npm install zur Lücke wird: ChainDrop ohne Panik"
language: "de"
default_language: "en"
canonical_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=de"
json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=de"
api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=de"
channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity"
channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-08-09T18:00:29+00:00"
updated_at: "2026-08-09T18:00:29+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=ar"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=ar"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=de"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=de"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=en"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=en"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=es"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=es"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=fr"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=fr"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=pl"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=pl"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=ru"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=ru"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09?lang=zh"
    markdown_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.md?lang=zh"
    json_url: "https://publicasta.com/cybersecurity/chaindrop_shai_hulud_npm_install_secrets_2026_08_09.json?lang=zh"
---

# Wenn npm install zur Lücke wird: ChainDrop ohne Panik

> Eine ruhige Einordnung der Shai-Hulud-Welle in npm: was passiert ist, wo Provenance endet und wie Teams CI-Secrets prüfen, ohne Downloadzahlen mit Opfern zu verwechseln.

Eine normale Installation von Abhängigkeiten sollte langweilig sein. In der neuen ChainDrop-Welle rund um Shai-Hulud wurde genau dieser Routinepunkt gefährlich: Ein Runner oder Entwicklerrechner löste ein kompromittiertes npm-Paket auf, das Paket führte während der Installation ein Lifecycle-Skript aus, und die Umgebung, in der oft Release-Token und Cloud-Zugänge liegen, wurde zur Angriffsfläche.

 ![Abhängigkeitsgraph mit Warnknoten, CI-Runner und geschützten Geheimnissen](https://publicasta.com/storage/projects/9/pages/290/2026/08/97750d89-bcf8-4d9f-8916-37c6bd3565a3.webp)

 ## Was zwischen dem 4. und 9. August geschah

 Aikido, Socket, SafeDep, JFrog, Unit 42, Wiz, Endor Labs und andere Teams beschrieben eine schnelle npm-Supply-Chain-Kampagne rund um Keyv und Cacheable. Nach Aikido begann der erste sichtbare Cluster mit einem kompromittierten Veröffentlichungsweg für `keyv@6.0.0` und verwandte Pakete wie `flat-cache`, `file-entry-cache`, `cacheable-request`, `cacheable`, `@cacheable/memory` und `cache-manager`. The Hacker News fasste die Woche später als wurmartige Kampagne zusammen, die sich auf Hunderte Paketartefakte ausweitete.

 Die Zahlen unterscheiden sich, weil die Lage während der Analysen in Bewegung war. JFrog sprach von mehr als 400 betroffenen Paketen, SafeDep und Unit 42 veröffentlichten zu anderen Zeitpunkten höhere Paket- oder Versionszahlen, Endor Labs betonte enorme Download-Volumina einzelner Abhängigkeitspfade. Diese Werte darf man weder addieren noch als Opferzahl lesen. Sie messen Pakete, Versionen oder Downloads, nicht die Zahl kompromittierter Maschinen.

 ## Warum der Fall mehr ist als ein weiteres Schadpaket

 Viele npm-Vorfälle beginnen mit einem Namensimitat oder einer kaum genutzten Bibliothek. ChainDrop ist unangenehmer, weil der Einstieg auch Abhängigkeiten betraf, die Teams transitiv erhalten. Ein Entwickler kann `keyv` nie direkt auswählen und es trotzdem über ein Framework, eine Cache-Schicht, einen Linter, ein Build-Werkzeug oder eine Serverbibliothek bekommen. Deshalb zählen Lockfiles mehr als Erinnerung: Die gefährliche Version kann mehrere Ebenen unter dem Paket liegen, das man bewusst installiert hat.

 Die Kampagne traf außerdem Vertrauenssignale, die zurecht genutzt werden. Forschende berichteten, dass bösartige Versionen über legitim wirkende Release-Workflows veröffentlicht wurden und gültige Provenance zeigen konnten. Provenance bleibt nützlich, beantwortet aber eine enge Frage: Welcher Workflow hat das Paket unter welcher Identität und aus welchem Repository-Kontext erzeugt? Sie beweist nicht, dass Maintainer-Konto, Release-Commit, Workflow-Eingaben oder Zugangsdaten sauber waren.

 ## Der Weg über Installationsskripte

 Die öffentlichen Berichte beschreiben eine klare Kette. Eine kompromittierte Version fügte einen Lifecycle-Befehl wie `preinstall` hinzu, der `node setup.mjs` startete. Danach lud das Skript verschleierten JavaScript-Code; genannt wurden Dateien wie `Math_Symbol.js` oder `math_init.js`. Bun diente in Teilen als praktischer Runtime. Bun war nicht kompromittiert, sondern wurde vom Payload genutzt.

 Im CI-System oder auf dem Entwicklerrechner suchte die Malware nach Geheimnissen: npm- und GitHub-Token, Cloud-Zugangsdaten, Vault- und Kubernetes-Material, SSH-Schlüssel, `.env`, Terraform-State, Docker- und Helm-Konfigurationen sowie temporäre Secrets von GitHub-Actions-Runnern. Gerade im Runner können kurzlebige Credentials oder OIDC-abgeleitete Token während eines Jobs in Umgebung oder Speicher auftauchen.

 Die wurmartige Ausbreitung kam über Veröffentlichungsrechte. Mit npm-Publishing-Token konnte der Payload infizierte Versionen anderer Pakete des Opfers veröffentlichen. Mit GitHub-Zugriff beschrieben die Analysen Repository-Änderungen und mögliche Persistenzflächen, etwa Dateien für VS Code tasks und Claude Code settings. Nicht jede solche Datei startet automatisch, aber sie zeigt, dass normale Entwicklerautomatisierung zum nächsten Einstieg werden sollte.

 ## Prüfen und reagieren

 Beginnen Sie mit Belegen. Suchen Sie die exakten Paketnamen und Versionen aus den Listen von Aikido, SafeDep, Socket, JFrog, Unit 42 und anderen in `package-lock.json`, `npm-shrinkwrap.json`, `pnpm-lock.yaml`, `yarn.lock`, Bun-Lockfiles, internen Mirrors und Scanner-Protokollen. Direkte Abhängigkeiten reichen nicht; die transitive Auflösung ist der Kern des Vorfalls.

 Klären Sie danach, ob während des relevanten Fensters tatsächlich installiert wurde. CI-Logs, Build-Zeitpunkte, Cache-Zeitstempel, Container-Layer und Shell-Historien trennen eine theoretische Abhängigkeit von ausgeführtem Code. Wenn eine betroffene Version nur im Lockfile steht, kann die Antwort begrenzt bleiben. Wenn sie in einer Umgebung mit Secrets lief, behandeln Sie diese Umgebung als exponiert.

 Ein Update auf “latest” reicht nicht. Es verhindert künftige Installationen der bekannten schlechten Version, holt aber kein kopiertes Token zurück. Isolieren Sie Runner oder Rechner, sichern Sie nötige Logs, bauen Sie ephemere Runner neu und prüfen Sie Caches, Umgebungsvariablen, Entwicklerwerkzeuge und Repositories. Widerrufen Sie npm- und GitHub-Token, prüfen Sie Maintainer, 2FA und Rechte, und rotieren Sie Cloud-, Vault-, Kubernetes-, SSH- und Deployment-Secrets, die erreichbar waren.

 Dauerhaft sollte man Installationsskripte als privilegierte Codeausführung behandeln. Nutzen Sie `--ignore-scripts`, wo es passt, genehmigen Sie notwendige Skripte ausdrücklich, testen Sie npm-12-Kontrollen und Entsprechungen in pnpm, Yarn und Bun, setzen Sie Mindestalter für Releases in automatischen Installationen, halten Sie Runner ephemer und trennen Sie Installieren, Testen und Veröffentlichen. ChainDrop beweist nicht das Scheitern von Open Source; es erinnert daran, dass `npm install` Code in der Nähe der Schlüssel ausführt.
