KI-Code-Assistenten können durch einen bösartigen .git/config-Eintrag gekapert werden, der die Git-Funktion core.fsmonitor ausnutzt. Dies ermöglicht es einem nicht vertrauenswürdigen Repository, Befehle auf dem Rechner eines Entwicklers auszuführen, sobald der Assistent die Dateien scannt.

Die Schwachstelle trat bei mehreren populären Agenten auf – Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build und Hermes. Bei den gepatchten Agenten funktioniert der Exploit nicht mehr; die anderen bleiben anfällig. Es sind keine zusätzlichen Klicks oder Bestätigungen erforderlich, und der bösartige Code wird mit den eigenen Berechtigungen des Benutzers ausgeführt, außerhalb jeder Sandbox, die der KI-Agent bereitstellen mag.

Wie der Angriff den Entwickler erreicht

  • Ein Auftragnehmer packt ein Projekt als ZIP-Datei und versendet es per E-Mail.
  • Ein Teammitglied teilt einen Ordner auf einem Netzlaufwerk.
  • Ein USB-Stick mit einer Codebasis wird übergeben.

In jedem Fall kommt das Repository als Verzeichnis an, das bereits einen .git-Ordner enthält. Wenn ein KI-Assistent den Ordner öffnet, führt er im Hintergrund typischerweise git status aus, um eine Übersicht des Codes zu erstellen. Git beschleunigt diesen Vorgang mit der Einstellung core.fsmonitor, die Git anweist, ein externes Programm aufzurufen, um das Dateisystem auf Änderungen zu überwachen. Wenn die .git/config-Datei des Repositories einen bösartigen Befehl für core.fsmonitor definiert, führt Git diesen automatisch aus, ohne den Benutzer zu fragen.

Da der Befehl von Git selbst gestartet wird, erbt er die Rechte des Benutzers und umgeht jede Sandbox, die das KI-Tool eingerichtet haben mag. Der Exploit wird nicht während eines normalen git clone, git fetch oder git pull ausgelöst; er wird erst aktiv, wenn das Repository entpackt wird und die .git-Metadaten bereits vorhanden sind.

Warum das Problem wichtig ist

Entwickler verlassen sich zunehmend auf KI-Assistenten, um Vervollständigungen vorzuschlagen, Code zu refactoren oder ganze Module zu generieren. Diese Tools benötigen eine schnelle Momentaufnahme des Dateibaums des Projekts und rufen daher im Hintergrund Git-Befehle auf. Wenn ein bösartiges Repository in diesem Moment Code ausführen kann, verschafft sich ein Angreifer ohne sichtbare Warnung Zugriff auf die Workstation des Entwicklers. Die potenziellen Auswirkungen reichen vom Diebstahl von Zugangsdaten bis hin zur Installation persistenter Backdoors – und das alles, während der Benutzer glaubt, den Code lediglich mit einem KI-Helfer zu „überprüfen“.

Ein vergiftetes Repository erkennen

Bevor Sie ein Repository an einen Assistenten übergeben, führen Sie Folgendes aus:

git config --get core.fsmonitor

Eine nicht leere Ausgabe bedeutet, dass ein Programm automatisch ausgeführt werden soll. Für eine umfassendere Suche listen Sie alle verdächtigen Git-Einstellungen auf:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Wenn Sie Einträge finden, die Sie nicht selbst hinzugefügt haben, löschen Sie diese mit:

git config --local --unset core.fsmonitor

Beachten Sie, dass das Setzen von git config --global core.fsmonitor false Sie nicht schützt. Lokale Repository-Einstellungen überschreiben immer die globalen Einstellungen, sodass ein bösartiges Repository eine globale Regel einfach ignorieren kann.

Aktueller Patch-Status

  • Claude Code – gepatcht (fsmonitor)
  • Cursor – gepatcht
  • OpenAI Codex – gepatcht
  • Goose – gepatcht
  • Qwen Code – ungepatcht
  • Grok Build – ungepatcht
  • Hermes – ungepatcht

Entwickler, die die ungepatchten Agenten verwenden, sollten jedes eingehende Repository als potenziell gefährlich behandeln, bis sie entweder das Tool wechseln oder strengere lokale Git-Richtlinien durchsetzen.

Gegenargument der Git-Community

core.fsmonitor in Git ist ein legitimes Performance-Feature und kein Bug. Die Maintainer argumentieren, dass es in der Verantwortung der Aufrufer liegt, den Inhalt eines Repositories zu validieren, bevor Git-Befehle aufgerufen werden. Das globale Deaktivieren der Funktion ist eine einfache Gegenmaßnahme, aber wie bereits erwähnt, können lokale Überschreibungen diesen Schutz unterwandern. Die breitere Diskussion dreht sich nun darum, ob KI-Assistenten alle externen Git-Aufrufe in einer Sandbox ausführen oder die Verarbeitung von Repositories verweigern sollten, die benutzerdefinierte fsmonitor-Hooks enthalten.

Worauf man als Nächstes achten sollte

  • Updates der ungepatchten KI-Agenten – insbesondere Aussagen über das Sandboxing von Git-Aufrufen.
  • Potenzielle Änderungen im Standardverhalten von Git beim Umgang mit core.fsmonitor für nicht vertrauenswürdige Verzeichnisse.
  • Drittanbieter-Tools, die die .git/config eines Repositories bereinigen können, bevor es einen Assistenten erreicht.

Fazit

Eine einzige Zeile in einer versteckten Konfigurationsdatei kann eine KI-gestützte Annehmlichkeit in einen Vektor für Remote-Code-Ausführung verwandeln. Bis die anfälligen Agenten behoben sind, ist die sicherste Methode, jedes Repository, das außerhalb eines Standard-Clone-Workflows eingeht, zu prüfen und alle core.fsmonitor- oder ähnliche Hooks zu entfernen, bevor man einen KI-Assistenten den Code bearbeiten lässt.