Dein Abhängigkeitsscanner liest package.json. Der Angriff vom 4. August lag daneben, im Konfigurationsordner deines Editors.

Was am 4. August passiert ist

Die Analyse von Wiz zum Vorfall datiert den Beginn auf 9:00 UTC am 4. August 2026. Betroffen waren über 400 npm-Pakete, darunter keyv in Version 6.0.0, @cacheable/utils 2.5.1, cache-manager 7.2.10 und cacheable-request 13.0.20.

Der Weg hinein war unspektakulär und deshalb umso ernster: ein übernommenes GitHub-Konto eines Maintainers. Das ist der Standardweg seit Jahren, und dagegen hilft, was seit Jahren hilft, nämlich Hardware-Schlüssel, geschützte Branches und Veröffentlichungen aus einer nachvollziehbaren Pipeline statt vom Laptop.

Interessant ist die Reihenfolge. Laut der Analyse wurden zunächst Persistenz-Payloads in das Repository eingebracht und erst kurz danach neue Paketversionen veröffentlicht. Das Ziel war also nicht nur, Schadcode zu verteilen, sondern auf den Rechnern der Entwickler zu bleiben, auch wenn die betroffene Paketversion später zurückgezogen wird.

Und der Ort dieser Persistenz ist der Punkt, um den es hier geht: Hook-Konfigurationen von Claude Code und tasks.json von VS Code, konkret setup.mjs-Dateien in den Verzeichnissen .claude und .vscode.

Warum diese Dateien eine Ausführungsfläche sind

Konfiguration klingt harmlos. Bei Entwicklungswerkzeugen ist sie es seit Langem nicht mehr.

Eine tasks.json beschreibt Aufgaben, die die Entwicklungsumgebung ausführt. Eine Hook-Konfiguration eines Agenten beschreibt Befehle, die zu bestimmten Zeitpunkten laufen. Beides ist per Entwurf ausführbar, und beides läuft mit den Rechten der Person, die das Projekt geöffnet hat. Also mit Zugriff auf ihre Cloud-Zugangsdaten, ihre Schlüssel, ihre Repositories.

Der Unterschied zu einem postinstall-Skript in einem npm-Paket ist die Aufmerksamkeit. Über postinstall wird seit Jahren diskutiert, es gibt Schalter dagegen, Scanner prüfen darauf, Sicherheitsteams kennen es. Über den Inhalt eines .vscode-Ordners im geklonten Repository denkt kaum jemand nach, und über einen .claude-Ordner denken viele Teams zum ersten Mal nach, seit es ihn gibt.

Die Zielliste der Payload bestätigt, worum es ging. Laut der Analyse wurden Cloud-Zugangsdaten, Infrastruktur-Geheimnisse, Entwickler-Zugangsdaten, KI-bezogene Konfigurationsdateien und Krypto-Wallets gesucht, dazu CI/CD-Umgebungen und Kubernetes-Konfigurationen. Ausdrücklich genannt sind auch die Anmeldespeicher von Claude, OpenAI, Codex, Cursor und Gemini.

Das ist bemerkenswert, weil ein API-Schlüssel für ein Modell inzwischen ein Zugangsdatum wie jedes andere ist: Er kostet Geld, er hat Rechte, und er taucht in keiner klassischen Rechteverwaltung auf.

Der strukturelle Punkt

Über die letzten zwei Jahre ist eine neue Kategorie von Dateien in Repositories eingezogen, die drei Eigenschaften zugleich hat, und diese Kombination ist neu.

Sie ist ausführbar. Hooks, Tasks und Agentenregeln sind Anweisungen, nicht nur Einstellungen.

Sie wird verteilt. Sie liegt im Repository und kommt mit jedem Klon, jedem Fork und jedem Pull Request mit.

Sie wird nicht geprüft. Weder von Werkzeugen, weil Scanner sie nicht kennen, noch von Menschen, weil eine Änderung an einer Konfigurationsdatei im Review-Diff wie Rauschen aussieht.

Code hat alle drei Eigenschaften ebenfalls, aber für Code existiert ein gewachsener Apparat: Reviews, Tests, Signaturen, Scanner, Freigabeprozesse. Für Agentenkonfiguration existiert davon fast nichts, obwohl sie mit derselben Berechtigung läuft.

Unser Report zu Lizenz- und Governance-Risiken betrachtet die Beschaffungsseite dieses Problems, also die Frage, wer über eine kritische Komponente entscheidet. Der Vorfall vom 4. August zeigt die Betriebsseite derselben Frage: Es genügt nicht zu wissen, welche Pakete du einsetzt. Du musst auch wissen, welche ausführbaren Anweisungen mit ihnen ins Haus kommen.

Was konkret zu tun ist

Die gute Nachricht ist, dass die Gegenmaßnahmen technisch einfach sind. Die weniger gute ist, dass sie eine Entscheidung verlangen, die viele Teams noch nicht getroffen haben.

Sofort, falls betroffen. Die genannten Paketversionen in Lockdateien und Build-Artefakten suchen, nicht nur in package.json. Bei Fund gilt das übliche Vorgehen für kompromittierte Entwicklungsumgebungen: Zugangsdaten rotieren, und zwar auch die, an die man zuerst nicht denkt, also Modell-API-Schlüssel, Registry-Token und persönliche Zugriffstoken.

Konfigurationsordner in die Prüfung aufnehmen. .vscode, .claude und die Äquivalente anderer Werkzeuge gehören in den Review wie Quellcode. Eine Änderung dort ist eine Änderung an ausführbarem Verhalten.

Prüfen, ob eure Scanner diese Pfade überhaupt lesen. Die Antwort ist bei den meisten Werkzeugen aktuell nein. Das ist keine Kritik an den Werkzeugen, sondern eine Information, die man haben muss, bevor man sich auf sie verlässt.

Trennen, was zusammen keinen Sinn ergibt. Ein Entwicklungsrechner, auf dem produktive Cloud-Zugangsdaten liegen, ist eine Entscheidung, keine Naturgegebenheit. Kurzlebige Anmeldungen statt langlebiger Schlüssel reduzieren den Wert eines erfolgreichen Zugriffs erheblich.

Veröffentlichungen aus der Pipeline statt vom Laptop. Das adressiert den Einstiegsweg, nicht die Persistenz, aber es ist die Maßnahme mit der besten Wirkung pro Aufwand und hilft gegen die gesamte Klasse.

Der Teil, über den ungern gesprochen wird

Es liegt nahe, aus diesem Vorfall ein Argument gegen KI-gestützte Entwicklung zu machen. Das wäre bequem und falsch.

Der Angriff hat nicht funktioniert, weil ein Modell etwas Falsches getan hätte. Er hat funktioniert, weil ein Werkzeug ausführbare Konfiguration aus einem Repository liest, das aus dem Internet kommt, und weil niemand diese Dateien prüft. Dieselbe Schwäche hatten Editoren und Build-Systeme lange bevor es Agenten gab. Neu ist nur, dass jetzt mehr solcher Dateien im Umlauf sind und dass sie in Repositories liegen, die täglich geklont werden.

Unser Evidenzbericht zu KI-gestützter Softwareentwicklung kommt an anderer Stelle zu einer verwandten Beobachtung: Der Engpass verschiebt sich vom Schreiben zum Prüfen. Dieser Vorfall zeigt dieselbe Verschiebung auf der Sicherheitsseite. Es entsteht mehr ausführbarer Inhalt, der durch dieselbe Anzahl Augen muss, und ein Teil davon sieht nicht wie Code aus.

Die ehrliche Konsequenz ist unangenehm für alle Beteiligten: Wenn Agentenkonfiguration mit denselben Rechten läuft wie Code, muss sie denselben Weg durch das Review nehmen wie Code. Das kostet Aufmerksamkeit, und Aufmerksamkeit ist die Ressource, die in genau diesen Teams gerade am knappsten ist.

Warum das nicht der letzte Vorfall dieser Art war

Die Angriffsfläche wächst, weil die Zahl der ausführbaren Konfigurationsformate wächst. Jedes neue Werkzeug bringt ein eigenes mit, jedes davon liegt im Repository, und keines davon hat einen etablierten Prüfpfad.

Wer sich darauf vorbereiten will, sollte nicht auf Signaturen für ein bestimmtes Muster warten, sondern eine Regel setzen, die unabhängig vom Werkzeug trägt: Jede Datei, die dazu führen kann, dass auf einem Entwicklungsrechner ein Befehl läuft, ist Code und wird wie Code behandelt. Diese Regel ist unbequem, weil sie einige Dateien erfasst, die man bisher durchgewinkt hat. Sie hat aber den Vorteil, dass sie auch für das Werkzeug gilt, das nächstes Jahr dazukommt.

Wie sich Zugangsdaten, Zugriffe und Freigabewege so ordnen lassen, dass ein kompromittierter Entwicklungsrechner nicht gleich die Produktion bedeutet, beschreibt unsere Seite zu Security und Härtung. Der Vorfall vom 4. August hat nichts erfunden. Er hat nur eine Annahme getestet, die viele Teams hatten, ohne sie je ausgesprochen zu haben.