Wenn ein fremdes Repo Deine KI konfiguriert. Der ChainDrop-Fall

Diese Academy erklärt an vielen Stellen, wie Du Deiner KI beim Start automatisch Kontext mitgibst. Ein Hook, der bei jeder neuen Sitzung feuert, ist eines der nützlichsten Werkzeuge im ganzen Setup. Im August 2026 hat jemand denselben Mechanismus als Verbreitungsweg benutzt.

Das ist kein Grund, Hooks abzuschaffen. Es ist ein Grund, sie so zu behandeln wie das, was sie sind: Code, der ohne Nachfrage läuft. Dieses Playbook zeigt, was passiert ist, wie Du prüfst, ob es Dich betrifft, und in welcher Reihenfolge Du reagierst. Die Reihenfolge ist der interessante Teil, denn dort sind sich die Fachleute nicht einig.

1. Was passiert ist

Am 4. August 2026 wurde der Betreuer-Zugang hinter zwei sehr verbreiteten npm-Paketen übernommen, keyv und cacheable. Der eingeschleuste Schadcode, je nach Quelle ChainDrop oder Mini-Shai-Hulud genannt, hat sich binnen Stunden selbst weiterverteilt: über 400 Pakete in mehr als 1700 Versionen. Elastic beziffert die betroffene Reichweite auf über 1,3 Milliarden Downloads pro Monat, keyv allein auf rund 600 Millionen.

Diese Zahlen beschreiben Reichweite, nicht Infektionen. Nicht jeder Download ist ein befallener Rechner. Aber sie sagen, wie viele Projekte das Zeug potenziell angefasst hat, und das ist eine große Zahl.

Der Teil, der Dich hier betrifft, ist nicht der npm-Teil. Der Wurm schreibt in befallene Projektordner eine Start-Konfiguration für Deine KI-Werkzeuge. Konkret einen Start-Hook in .claude/settings.json und eine Aufgabe in .vscode/tasks.json, die beim Öffnen des Ordners läuft.

2. Warum Dich das trifft, auch ohne Installieren

Das ist der Punkt, der die meisten überrascht.

Wenn eine Schadfunktion im Installationsschritt eines Pakets sitzt, ist die Abwehr klar: nicht installieren, nichts passiert. Bei einem Start-Hook in der Projektkonfiguration ist das anders. Der Auslöser ist nicht der Bau, sondern der Start Deines Werkzeugs im Projekt.

Zwei getrennte Wege, und beide brauchen eine Kleinigkeit mehr als "Ordner anklicken":

Der Agent-Hook feuert beim Start von Claude Code in diesem Verzeichnis. Kein npm install, kein Build: der Startbefehl selbst ist der Auslöser. Beim allerersten Start in einem neuen Verzeichnis kommt allerdings die Vertrauensabfrage dazwischen, und die ist eine echte Schranke. In einem Projekt, das Du schon einmal bestätigt hast, genügt danach claude, und der Hook läuft mit.

Die Editor-Aufgabe hängt an runOn: "folderOpen" in .vscode/tasks.json. Sie läuft nur, wenn zwei Dinge zusammenkommen: der Ordner gilt als vertrauenswürdig (Workspace Trust) und automatische Aufgaben sind dort erlaubt. Das sind zwei getrennte Schalter, einer allein genügt nicht.

Der praktische Schluss bleibt derselbe, nur präziser: Wer meint, ein fremdes Projekt sei ungefährlich, solange er es nur anschaut und nicht baut, irrt sich. In einem Projekt, das Du schon freigegeben hast, genügt der eigene Werkzeugstart. Beim Editor sind es zwei Freigaben, und Vertrauen für den Ordner räumt nur die erste ab: automatische Aufgaben müssen zusätzlich erlaubt sein. Das ist der Unterschied zwischen "es kann passieren" und "es passiert bei mir".

Dazu kommt die Ausbreitung: Mit einem erbeuteten Zugangstoken verteilt der Wurm dieselben Hooks auf bis zu 50 Zweige pro erreichbarem Repository. Ein einziger befallener Rechner kann so eine ganze Organisation mit vorbereiteten Konfigurationsdateien versehen.

3. Worauf es abgesehen hat

Der Sammler im Schadcode prüft über 300 Muster für Zugangsdaten. Und er zielt namentlich auf die Zugänge von Anthropic, Claude, Codex, Cursor und Gemini.

Das ist die eigentliche Nachricht dieses Vorfalls. KI-Zugangsdaten sind kein Nebenschauplatz mehr, auf den ein Sammler zufällig stößt, sondern ein ausdrückliches Ziel. Wer einen API-Schlüssel in einer Konfigurationsdatei liegen hat, sollte das ab jetzt so behandeln wie ein Passwort für sein Bankkonto.

4. Der Sofort-Check, vier Prüfungen

Geh in jedes Projekt, das Du in den letzten Wochen geöffnet hast, und schau nach, ob dort Konfigurationsdateien liegen, die Du nicht selbst angelegt hast.

# Liegt eine Projekt-Konfiguration da, die Du nicht kennst?
ls -la .claude/ .vscode/ 2>/dev/null

# Was steht drin? Interessant sind Hooks und Tasks, die beim Start feuern.
# settings.local.json nicht vergessen: die ist projektlokal, steht meist in der
# .gitignore und kann genauso Hooks enthalten.
cat .claude/settings.json .claude/settings.local.json 2>/dev/null
cat .vscode/tasks.json 2>/dev/null

# Wer hat die Dateien wann angefasst, über ALLE Zweige, nicht nur den aktuellen?
# -p zeigt dabei den INHALT der Änderung. Ohne das siehst Du nur, DASS jemand
# etwas angefasst hat, und ein plausibel benannter Commit fällt nicht auf.
git log --all -p --format='%h %an %ad %s' --date=short -- .claude/ .vscode/

# Und liegt da etwas, das noch gar nicht committet ist?
# --ignored ist hier entscheidend: .claude/ steht in vielen Projekten in der
# .gitignore, und dann meldet ein normaler status-Aufruf brav "nichts zu sehen".
git status --short --untracked-files=all --ignored=matching -- .claude/ .vscode/

Was Dich aufhorchen lassen sollte: ein Eintrag, der beim Start etwas herunterlädt und direkt ausführt. Eine lange Zeichenkette, die nach kodiertem Text aussieht. Ein Befehl, der eine Adresse im Netz anspricht, die nichts mit dem Projekt zu tun hat.

Die Herkunftsfrage stellt sich je nach Datei anders. Bei den geteilten Dateien (settings.json, tasks.json) ist die Projekthistorie der Maßstab: Was dort steht und nicht als bewusste Änderung auffindbar ist, gehört geprüft. Bei settings.local.json funktioniert das nicht, denn die ist absichtlich lokal und steht normalerweise gerade NICHT in Git. Dort ist der Maßstab Dein eigenes Gedächtnis: Hast Du diesen Hook selbst angelegt? Wenn nicht, hat ihn jemand anderes dort hingeschrieben.

Die letzten beiden Befehle sind die wichtigsten, und --all ist dabei kein Detail. Ohne dieses Flag siehst Du nur die Historie, die von Deinem aktuellen Stand aus erreichbar ist. Genau das würde die Verteilung über bis zu 50 Zweige aus Schritt 2 verfehlen: Der Zweig, auf dem der Hook liegt, wäre unsichtbar, und der Check meldet Entwarnung. %an zeigt Dir dazu den Autor, denn ein Commit unter fremdem Namen ist ein Signal für sich.

Eine Konfigurationsdatei, die in einem Commit auftaucht, dessen Nachricht etwas ganz anderes beschreibt, ist ein Alarmzeichen unabhängig davon, was drinsteht.

Was diese Befehle nicht abdecken: Zweige, die nur beim Code-Hoster liegen und die Du nie geholt hast, sowie Forks und Pull Requests. Die schaust Du im Browser durch, und zwar von einem Gerät, dem Du vertraust.

5. Der Widerspruch, den Du kennen musst

Jetzt der Teil, bei dem Du gleich zwei Empfehlungen finden wirst, die sich widersprechen. Beide stammen von seriösen Analysten, und beide haben ein Argument.

Die eine Seite (JFrog, Microsoft, Unit 42) sagt: Zugangsdaten sofort erneuern. Standard bei jedem Datenabfluss, jede Minute zählt, ein gestohlener Schlüssel wird benutzt.

Die andere Seite (SANS Internet Storm Center) beschreibt einen Totmannschalter. Der Schadcode legt einen kleinen Dienst an, der den erbeuteten Zugangstoken minütlich prüft. Wird der Token ungültig, also genau in dem Moment, in dem Du ihn widerrufst, führt er eine ferngesteuerte Reaktion aus. Nach dieser Lesart ist das Widerrufen der Auslöser für die nächste Stufe. SANS empfiehlt deshalb: erst vom Netz trennen, dann bereinigen, danach erneuern.

Der Widerspruch ist echt, und ich löse ihn hier nicht durch einen Kompromiss auf. Wenn eine Fachwelt sich uneins ist, bekommst Du kein glattes Rezept, sondern eine Entscheidung.

Was der Streit betrifft und was nicht. Beide Seiten reden über den befallenen Rechner. Über eine Sache sind sie sich einig, und die ist die wichtigere: Deine Zugangsdaten sind möglicherweise schon abgeflossen, bevor Du überhaupt etwas gemerkt hast. Ein Angreifer, der sie hat, benutzt sie von seiner eigenen Maschine aus. Ihn stört es nicht im Geringsten, ob Dein Rechner am Netz hängt.

Deshalb ist "erst trennen, dann in Ruhe entscheiden" falsch, und ich hatte das hier zuerst so stehen. Die Isolation schützt nur davor, dass NEUE Daten abfließen und der Schadcode NEUE Befehle empfängt. Sie schützt nicht das, was schon weg ist. Wer die Sperrung aufschiebt, bis die Bereinigung fertig ist, lässt dem Angreifer genau diese Zeit für Deine Repositories, Cloud-Konten und Pipelines.

Der Weg, der beides zusammenbringt:

1. Den betroffenen Rechner vom Netz nehmen. Das ist unstrittig und dauert Sekunden.
2. Danach sofort widerrufen, aber von einem anderen, nachweislich sauberen Gerät aus. Handy, Zweitrechner, Rechner einer Kollegin. Der befallene bleibt dabei offline.

Damit verliert der Angreifer die Zugänge in dem Moment, in dem Du es merkst, statt Stunden später.

Was das mit dem Totmannschalter macht, ehrlich gesagt: Er ist damit nicht entschärft, sondern nur vertagt. Ein Dienst ohne Netz merkt in der Regel gar nicht, dass der Token gesperrt wurde. Der Auslöser bleibt scharf und wartet auf die nächste Verbindung. Genau deshalb ist der letzte Schritt in dieser Lage nicht "wieder ans Netz", sondern Neuaufsetzen.

Was Du dabei nicht tun darfst: den befallenen Rechner "kurz" wieder ans Netz hängen, um die Schlüssel zu erneuern. Dann sind die neuen sofort genauso weg wie die alten.

6. Die Reihenfolge, wenn Du etwas gefunden hast

1. Netzwerk trennen. WLAN aus, Kabel raus. Vor allen anderen Schritten, und der Rechner bleibt offline bis Schritt 6.
2. Von einem sauberen Gerät aus alles widerrufen. Handy oder Zweitrechner. KI-Schlüssel, Code-Hosting-Token, Cloud-Zugänge, aktive Sitzungen. Alles, was von der befallenen Maschine aus erreichbar war, nicht nur das Offensichtliche. Neue Schlüssel erzeugst Du dort ebenfalls, und sie kommen erst auf den befallenen Rechner, wenn der wieder als sauber gilt.
3. Beweise sichern. Kopier die verdächtigen Dateien weg, bevor Du sie löschst. Ohne sie kannst Du hinterher nicht sagen, was passiert ist. Behandle diese Kopie als kontaminiert: sie ist Beweismittel, kein Backup zum Zurückspielen.
4. Nachschauen, was sich eingenistet hat. Einen Start-Hook zu löschen reicht nicht, wenn daneben ein Dienst läuft, der ihn wieder anlegt. Schau in die Benutzerdienste Deines Systems und in die Autostart-Einträge.
5. Die Konfigurationsdateien entfernen und die Änderung im Projekt rückgängig machen, auf allen Zweigen, nicht nur auf dem, auf dem Du gerade stehst. Die fremden Zweige prüfst Du beim Code-Hoster im Browser, vom sauberen Gerät aus.
6. Neu aufsetzen, bevor die Maschine wieder ans Netz geht.

Warum Schritt 6 so hart ist. Konfigurationsdateien zu löschen und sichtbare Autostarts zu entfernen ist Eindämmung, kein Nachweis. Bei einem Schädling, der sich selbst weiterverteilt, gezielt Zugangsdaten sammelt und einen Totmannschalter mitbringt, kommt eins dazu: Der Auslöser hat offline nie ausgelöst, er wartet. Wer die Maschine nach einer Handbereinigung einfach wieder verbindet, gibt ihm genau diesen Moment.

Deshalb ist der belastbare Weg das Neuaufsetzen aus einem vertrauenswürdigen Abbild. Das klingt hart für einen Arbeitsrechner, ist aber der einzige Zustand, bei dem Du hinterher weißt, woran Du bist. Wer das nicht kann oder will, arbeitet mit einem bekannten Restrisiko weiter und sollte das wenigstens bewusst tun, statt es für erledigt zu halten. Die neuen Schlüssel gehören in jedem Fall erst auf diese Maschine, wenn sie als sauber gilt.

Wenn Du an Schritt 4 unsicher bist, ist das der Punkt, an dem professionelle Hilfe billiger ist als Raten. Ein halb bereinigtes System ist schlimmer als ein bekannt infiziertes, weil Du aufhörst hinzuschauen.

7. Die npm-Frage, ebenfalls uneindeutig

Ein zweiter Punkt, an dem sich die Quellen unterscheiden. JFrog schreibt, dass unter neueren npm-Versionen die Skripte beim Installieren standardmäßig nicht mehr laufen, der Schadcode dort also beim Installieren nicht zündet. Microsoft beschreibt die Ausführung als Regelfall.

Beide können recht haben, weil es von Deiner Umgebung abhängt. Aber die Versionsnummer allein beantwortet die Frage nicht. Was zählt, ist die wirksame Einstellung, und die kann aus der globalen Konfiguration, aus einer .npmrc im Projekt oder aus einer Umgebungsvariable kommen. Frag deshalb die Einstellung selbst ab, nicht die Version:

npm config get ignore-scripts

Steht dort false, laufen Installations-Skripte bei Dir, egal welche npm-Version Du hast. Und selbst wenn true dort steht: verlass Dich nicht darauf, sondern schreib es beim konkreten Lauf dazu.

npm ci --ignore-scripts

Vor allem aber: Das schützt nur die eine Seite. Gegen den Start-Hook aus Schritt 2 hilft diese Einstellung überhaupt nicht, denn der hat mit npm nichts zu tun. Zwei verschiedene Wege, und nur einer davon wird hier berührt.

8. Dauerhaft: Hooks wie Code behandeln

Die eigentliche Konsequenz ist nicht der eine Wurm, sondern eine Gewohnheit.

Eine Konfigurationsdatei, die beim Start Befehle ausführt, ist ausführbarer Code. Sie sieht nur nicht so aus, weil sie in einem Ordner mit einem Punkt davor liegt und niemand sie im Review anschaut. Genau deshalb funktioniert der Angriff.

Drei Gewohnheiten, die das abstellen:

Erstens, .claude/settings.json, .claude/settings.local.json und .vscode/tasks.json gehören in Deine Aufmerksamkeit wie eine Datei mit Programmcode. Wenn Du in einem fremden Projekt arbeitest, schau in alle drei einmal rein, bevor Du das Werkzeug startest.

Zweitens, trenn die drei Reichweiten sauber. Es gibt persönlich-global (gilt überall, gehört in Deine Benutzerkonfiguration), projektweit-geteilt (.claude/settings.json, wird mit dem Team versioniert) und projektlokal-persönlich (.claude/settings.local.json, bleibt bei Dir). Ein Hook, den nur Du und nur in diesem Projekt brauchst, gehört in die dritte Schublade, nicht in die globale. Wer ihn nach global schiebt, lässt ihn ab sofort in jedem Repository laufen und vergrößert die Angriffsfläche, statt sie zu verkleinern.

Drittens, bei fremden Projekten aus dem Netz gilt dieselbe Vorsicht wie bei fremden MCP-Servern. Wie man die prüft, steht in Fremde MCP-Server sicher prüfen, und das Verfahren überträgt sich fast eins zu eins.

9. Wenn Du im Team arbeitest

In einem geteilten Repository ist die Projektkonfiguration eine gemeinsame Angriffsfläche. Wer sie ändern darf, ändert die Startbedingungen für alle im Team.

Behandle Änderungen an diesen Dateien deshalb als Änderung mit Prüfpflicht. Kein Durchwinken. Wer einen Start-Hook hinzufügt, schreibt dazu, was er tut und warum, so wie bei jeder anderen Änderung an Code, der in der Produktion läuft.

Wenn Deine Abläufe automatisiert laufen, kommt eine zweite Schicht dazu: dort wird fremder Inhalt oft ungefiltert weiterverarbeitet. Das ist ein eigenes Thema, Claude Code im Hintergrund betreiben geht auf die Mechanik ein.

10. Die Lehre, die bleibt

Ein Start-Hook ist deshalb so nützlich, weil er ohne Nachfrage läuft. Genau deshalb ist er auch ein Ziel. Das ist keine Schwäche der Werkzeuge, das ist die Kehrseite der Bequemlichkeit, und sie gilt für jeden Automatismus, den Du Dir baust.

Der praktische Schluss ist unspektakulär: Schau einmal hin, bevor Du ein fremdes Projekt öffnest. Halt Deine Zugangsdaten aus Dateien heraus, die mit dem Projekt mitreisen. Und wenn Du irgendwo automatisch etwas startest, wisse, was es tut.

Was kommt als nächstes

Wenn Du Deine Hooks jetzt sowieso durchgehst, ist Hooks debuggen, wenn nichts feuert der passende Nachbar: dieselben Dateien, andere Richtung. Für die Zugangsdaten-Seite ist MCP über stdio absichern der Einstieg.

Ein Wort zum Thema Sicherung, weil hier ausnahmsweise eine andere Reihenfolge gilt: Memory-Backup vor Update beschreibt Sicherungen für den Normalfall, und dort stimmt "erst sichern, dann anfassen". Im Verdachtsfall nicht. Da gilt: erst isolieren, dann vom sauberen Gerät widerrufen, und erst danach Beweise sichern, bevor Du lokal etwas veränderst. Eine Kopie, die nach einer möglichen Infektion entsteht, ist Beweismittel und kein Wiederherstellungspunkt. Zum Zurückspielen taugt nur ein Stand aus der Zeit davor. Wer das verwechselt, holt sich den Schadcode aus dem eigenen Backup zurück.

Source

Stand 9. August 2026. Der Vorfall ist fünf Tage alt und wird weiter untersucht, Details können sich ändern. Die Quellenlage zu den Punkten in Schritt 5 und 7 bleibt widersprüchlich; dieses Playbook legt den Widerspruch offen und trifft daraus eine vorsichtige Handlungsentscheidung, statt so zu tun, als gäbe es ein einhelliges Rezept.

• Elastic Security Labs zur Analyse des Wurms: elastic.co/security-labs
• JFrog zur Ausbreitung über npm: research.jfrog.com
• Microsoft zur Anatomie des selbstverbreitenden Wurms: microsoft.com/security/blog
• Unit 42 mit einer weiteren unabhängigen Analyse: unit42.paloaltonetworks.com
• SANS Internet Storm Center zum Totmannschalter und zur abweichenden Reihenfolge: isc.sans.edu/diary/33218