#Künstliche Intelligenz · 5 Min. Lesezeit · Tim Rinkel

ORDNER GEÖFFNET, CODE GESTARTET! Ein fremdes Projekt kapert deinen KI-Assistenten

ORDNER GEÖFFNET, CODE GESTARTET! Ein fremdes Projekt kapert deinen KI-Assistenten

Du bekommst ein Projekt als ZIP-Archiv. Von einem Kollegen, aus einem geteilten Laufwerk, von einem USB-Stick. Du entpackst es, lässt deinen KI-Assistenten hineinschauen — und in dem Moment läuft fremder Code auf deinem Rechner. Ohne Prompt. Ohne Freigabe. Ohne dass das KI-Modell überhaupt beteiligt war.

Das ist die Kurzfassung von GitSpawn, einer Untersuchung der Sicherheitsfirma Manifold Security. Sie hat acht Schwachstellen in sieben KI-Coding-Agenten auf der Kommandozeile gemeldet. Zum Zeitpunkt der Veröffentlichung am 2. September waren vier davon noch offen.

DER TRICK STECKT NICHT IN DER KI

Manifold bringt es selbst auf den Punkt: „Die Schwachstelle steckt nicht im Modell und in nichts Neuem. Sie steckt in der ganz gewöhnlichen Installation darunter.“

Gemeint ist eine Git-Einstellung namens core.fsmonitor. Ihr Wert ist kein Schalter, sondern ein Befehl. Git ruft ihn auf, um schnell herauszufinden, welche Dateien sich geändert haben. Das ist eine Beschleunigungsfunktion, seit Jahren völlig legitim.

Der Haken: Git liest diesen Wert aus .git/config — also aus dem Ordner des Projekts selbst. Und jede Aktion, die den Index auffrischt, führt den Befehl aus. Auch git status. Auch git diff.

Genau diese Kommandos setzen KI-Agenten beim Start ab, um zu klären, in welchem Branch sie stecken und was sich verändert hat. Sie tun das im Hintergrund und lassen die Konfiguration dabei unangetastet.

WANN ES ZÜNDET — UND WANN NICHT

Der wichtigste Satz für die Praxis: Ein normales git clone reicht nicht. Der Angriff funktioniert nur, wenn das Verzeichnis mitsamt seinem .git-Ordner als Dateien bei dir ankommt. Also über ein Archiv, ein Netzlaufwerk, einen Sync-Ordner oder einen Stick.

Dafür zündet es früher, als man erwartet:

  • Claude Code und Hermes Agent: bevor du den Workspace als vertrauenswürdig bestätigt hast
  • Qwen Code: bevor du dich überhaupt angemeldet hast
  • Grok Build: beim ersten Tastendruck

Bei goose genügt der Aufruf goose review in einem präparierten Ordner. Im Advisory dazu steht der Satz, der die Sache zusammenfasst: kein abgeschickter Prompt, kein Modellaufruf, keine Werkzeugfreigabe, kein Vertrauensdialog. Der Befehl läuft, bevor goose das Modell überhaupt kontaktiert. GitHub hat dafür CVE-2026-72718 mit CVSS 4.0 und 7,0 Punkten vergeben — der einzige Score in diesem ganzen Fundkomplex.

WER GEPATCHT HAT — UND WER NICHT

Der Stand vom 2. September, so wie Manifold ihn nach dem Nachtest am 1. September dokumentiert:

  • goose — behoben in 1.44.0
  • Codex CLI — betroffen 0.102.0 bis 0.130.0, behoben in 0.131.0
  • Claude Code — der core.fsmonitor-Pfad wurde in 2.1.196 geschlossen; ein zweiter Weg über claude ultrareview war in 2.1.252 noch offen
  • Hermes Agent, Qwen Code, Grok Build — Fix zu diesem Zeitpunkt ausstehend

OpenAI hat am selben Tag drei eigene CVEs für Codex veröffentlicht, gemeldet von drei voneinander unabhängigen Forschungsgruppen. Im Eintrag zu CVE-2026-19592 heißt es, das Hilfsprogramm laufe außerhalb der Sandbox und ohne Freigabedialog, und der fremde Code könne alles lesen, ändern oder löschen, worauf dein Benutzerkonto Zugriff hat.

DAS MUSTER IST ÄLTER ALS DIE KI-AGENTEN

Sonar hat dieselbe Stelle schon im April beschrieben. Damals hatte Anthropic die Startreihenfolge in Claude Code Version 2.0.34 bereits einmal umgebaut, damit git status erst nach dem Vertrauensdialog läuft. Diese Version kam am 5. November 2025. Manifold fand das gleiche Startverhalten in 2.1.193 wieder — ausgeliefert am 25. Juni 2026.

Und noch weiter zurück: Denselben Umgehungsweg am Vertrauensdialog gab es in Visual Studio Code vor 1.63.1 und in den JetBrains-IDEs vor 2021.3.1. Die Sicherheitsfirma Cobalt hat es in einem Red-Team-Text im Dezember auf den Punkt gebracht: Missbrauch von FSMonitor nutzt eine echte Funktion aus, keinen Fehler.

KEINE ANGRIFFE — BISHER

Zur Einordnung gehört auch das: Keine der Quellen berichtet von tatsächlicher Ausnutzung. The Hacker News hat am 2. September den KEV-Katalog der US-Behörde CISA geprüft — keiner dieser CVEs steht darin.

VIER HANDGRIFFE, DIE DIR DIE SACHE VOM HALS HALTEN

  1. Schau in .git/config, bevor du einen empfangenen Ordner mit einem Agenten öffnest. Verdächtig sind core.fsmonitor, core.hooksPath und attr.tree.
  2. Im Zweifel gezielt nachfragen: git config --get core.fsmonitor
  3. Die globale Einstellung prüfen: git config --global --list | grep fsmonitor
  4. Und wenn du die Beschleunigung nicht brauchst, schalte sie generell ab: git config --global core.fsmonitor false

Der letzte Punkt kostet dich auf normalen Projekten praktisch nichts — und nimmt dem ganzen Trick die Grundlage.

Häufige Fragen

Bin ich betroffen, wenn ich Projekte nur per git clone hole?
Dann greift dieser Weg nicht. Beim Klonen legt Git die Konfigurationsdatei selbst an, die Werte des Angreifers kommen gar nicht erst mit. Gefährlich wird es, wenn ein Verzeichnis samt .git-Ordner als Dateien bei dir landet — über ein Archiv, ein Netzlaufwerk, einen Sync-Ordner oder einen USB-Stick.
Ist Claude Code jetzt sicher?
Teilweise. Den Weg über core.fsmonitor hat Anthropic laut Manifold mit Version 2.1.196 geschlossen. Ein zweiter Pfad über claude ultrareview war beim Nachtest am 1. September in Version 2.1.252 noch offen; welchen Konfigurationsschlüssel er nutzt, hält Manifold zurück. Ob spätere Versionen ihn schließen, sagt keine der Quellen.
Wird das schon ausgenutzt?
Keine der Quellen berichtet davon. The Hacker News hat am 2. September den KEV-Katalog der CISA in der Fassung 2026.09.01 mit 1.687 Einträgen geprüft und keinen der betroffenen CVEs gefunden. Das ist eine Momentaufnahme, keine Entwarnung auf Dauer.
Was verliere ich, wenn ich core.fsmonitor global abschalte?
Bei normal großen Projekten kaum etwas. Die Einstellung beschleunigt vor allem git status in sehr großen Repositories, indem ein Hintergrunddienst die Dateiänderungen meldet. Für die meisten Homelab- und Hobbyprojekte ist der Unterschied nicht spürbar.
Hilft die Sandbox meines Agenten?
Nein, und das ist der Kern des Problems. Git startet den Befehl selbst, nicht der Agent. Er läuft damit außerhalb der Sandbox, mit deinen normalen Benutzerrechten und ohne den Freigabedialog, den du bei Werkzeugaufrufen sonst siehst.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert