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

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, also Bausteine, die Entwickler in ihre eigene Software einbauen. 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 des Paketbetreuers. Das ist seit Jahren der Standardweg. Dagegen hilft, was seit Jahren hilft: Hardware-Schlüssel für die Anmeldung, geschützte Hauptzweige im Repository und Veröffentlichungen aus einer nachvollziehbaren Pipeline statt vom Laptop.

Interessant ist die Reihenfolge. Laut der Analyse wurden zuerst Dateien ins Repository eingebracht, die den Schadcode auf dem Rechner halten sollen. Erst kurz danach wurden neue Paketversionen veröffentlicht. Das Ziel war also nicht nur, Schadcode zu verteilen. Das Ziel war, auf den Rechnern der Entwickler zu bleiben, auch wenn die betroffene Paketversion später zurückgezogen wird.

Der Ort dieser Dateien ist der Punkt, um den es hier geht: Hook-Konfigurationen von Claude Code und die tasks.json von VS Code. Konkret lagen setup.mjs-Dateien in den Ordnern .claude und .vscode.

Warum diese Dateien Befehle ausführen

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

Eine tasks.json beschreibt Aufgaben, die die Entwicklungsumgebung ausführt. Ein Hook ist ein Befehl, den ein KI-Agent zu einem bestimmten Zeitpunkt automatisch startet, etwa bevor er eine Datei ändert. Beides ist dafür gebaut, Befehle auszuführen. Beides läuft mit den Rechten der Person, die das Projekt geöffnet hat. Also mit Zugriff auf ihre Cloud-Zugangsdaten, ihre Schlüssel und 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 in einem geklonten Repository denkt kaum jemand nach. Über einen .claude-Ordner denken viele Teams zum ersten Mal nach, seit es ihn gibt.

Die Zielliste des Schadcodes bestätigt, worum es ging. Laut der Analyse wurden Cloud-Zugangsdaten, Infrastruktur-Geheimnisse, Entwickler-Zugangsdaten, KI-bezogene Konfigurationsdateien und Krypto-Wallets gesucht, dazu Zugänge zu Build-Pipelines und Kubernetes-Konfigurationen. Ausdrücklich genannt sind die Anmeldespeicher von Claude, OpenAI, Codex, Cursor und Gemini.

Das ist bemerkenswert, weil ein API-Schlüssel für ein Sprachmodell 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 Art von Datei in Repositories eingezogen. Sie hat drei Eigenschaften zugleich und diese Kombination ist neu.

Sie führt Befehle aus. 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 wie Rauschen aussieht.

Code hat alle drei Eigenschaften ebenfalls. Für Code existiert aber 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: Die Gegenmaßnahmen sind technisch einfach. Die weniger gute: Sie verlangen eine Entscheidung, die viele Teams noch nicht getroffen haben.

Sofort, falls betroffen. Such die genannten Paketversionen in den Lockdateien und in den gebauten Artefakten, nicht nur in package.json. Eine Lockdatei hält fest, welche Version jedes Bausteins tatsächlich installiert wurde. Bei einem Fund gilt das übliche Vorgehen für kompromittierte Entwicklungsumgebungen: Zugangsdaten austauschen, 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 Gegenstücke anderer Werkzeuge gehören in den Review wie Quellcode. Eine Änderung dort ist eine Änderung an dem, was auf dem Rechner läuft.

Prüfen, ob eure Scanner diese Pfade überhaupt lesen. Bei den meisten Werkzeugen lautet die Antwort derzeit 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 machen einen erfolgreichen Zugriff deutlich weniger wert.

Veröffentlichungen aus der Pipeline statt vom Laptop. Das wirkt gegen den Einstiegsweg, nicht gegen das Bleiben. Es ist aber die Maßnahme mit der besten Wirkung pro Aufwand und hilft gegen die gesamte Klasse solcher Angriffe.

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. 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 den Review nehmen wie Code. Das kostet Aufmerksamkeit. Und Aufmerksamkeit ist in genau diesen Teams gerade die knappste Ressource.

Warum das nicht der letzte Vorfall dieser Art war

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

Wer sich vorbereiten will, sollte nicht auf Erkennungsmuster für einen bestimmten Angriff 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.

Was du diese Woche prüfen kannst

Öffne ein beliebiges Repository deines Teams und sieh nach, ob dort Ordner wie .vscode, .claude oder ähnliche liegen. Frag, wer die zuletzt geändert hat und ob das jemand gesehen hat. Frag euer Sicherheitsteam oder euren Dienstleister, ob der Abhängigkeitsscanner diese Ordner liest. Und sieh nach, welche Zugangsdaten auf den Entwicklungsrechnern dauerhaft liegen. Die Antworten auf diese drei Fragen sagen mehr über eure Lage als jede Liste betroffener Paketversionen.

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.