Ein Entwickler bekommt ein Projekt nicht per normalem git clone, sondern als ZIP-Datei, über einen geteilten Ordner oder aus einem Kunden-Share. Er entpackt den Ordner, öffnet ihn mit einem KI-Coding-Agenten und will nur kurz fragen, warum die Tests fehlschlagen. Noch bevor er einen Prompt schreibt, startet das Tool im Hintergrund git status oder git diff, um Branch, Änderungen und Projektkontext zu verstehen. Genau an dieser scheinbar harmlosen Stelle setzt die neue GitSpawn-Klasse an: Die lokale Git-Konfiguration des empfangenen Repositories kann dafür sorgen, dass ein vom Angreifer gewählter Befehl auf dem Entwicklerrechner läuft.
Manifold Security veröffentlichte die Analyse am 2. September 2026 und spricht von acht Findings in sieben CLI-basierten KI-Coding-Agenten. Vier waren laut Manifold zum Veröffentlichungszeitpunkt noch ungepatcht. The Hacker News bestätigte die Kerndaten am selben Tag und verknüpfte die Fälle mit bestehenden advisories, unter anderem der GitHub Security Advisory zu Goose (GHSA-r5pp-p5r8-466r, CVE-2026-72718). Wichtig ist: Das ist keine magische Modell-Schwachstelle. Es ist ein klassischer Vertrauensbruch in der Entwickler-Toolchain, der durch Agenten-Automatisierung gefährlicher wird.
Der technische Kern: Git führt Konfiguration aus
Im Zentrum steht core.fsmonitor, eine legitime Git-Funktion für große Repositories. Statt bei jedem Statuslauf den gesamten Arbeitsbaum zu prüfen, kann Git einen Hilfsprozess fragen, welche Dateien sich geändert haben. Dieser Helper wird bei Index-Aktualisierungen ausgeführt, also etwa bei git status oder git diff. Git dokumentiert FSMonitor als Performance-Mechanismus; gefährlich wird er, wenn ein Tool die lokale .git/config eines untrusted Verzeichnisses ungefiltert respektiert.
Ein Angreifer muss dafür nicht Git selbst kompromittieren. Er legt ein Repository als Ordner mit bereits vorhandener .git/config ab und setzt dort beispielsweise einen FSMonitor-Helper. Ein normaler git clone, fetch oder pull überträgt diese lokale Konfiguration nicht. Der realistische Angriffsweg ist deshalb der Dateiweg: ZIP-Archiv, USB-Stick, Shared Drive, Sync-Ordner, Support-Bundle, Kundenprojekt oder ein bereits entpackter Workspace in einer VDI-Umgebung. Genau solche Wege existieren in Unternehmen regelmäßig, gerade wenn externe Dienstleister, Kunden, Agenturen oder interne Teams Code nicht immer sauber über Remote-Repositories austauschen.
KI-Coding-Agenten verstärken das Risiko, weil sie beim Öffnen eines Projekts sehr früh Kontext sammeln. Sie wollen wissen, welcher Branch aktiv ist, welche Dateien geändert wurden, welche Diffs vorliegen und welche Pfade zum Arbeitskontext gehören. Dafür rufen sie Git als Subprozess auf. Wenn dieser Aufruf die lokale Git-Konfiguration nicht neutralisiert, läuft der konfigurierte Helper mit den Rechten des Entwicklers. Die Agenten-Sandbox, Tool-Freigabe oder Workspace-Trust-Abfrage sieht den Befehl unter Umständen gar nicht, weil er nicht als vom Modell angeforderte Aktion erscheint, sondern als Nebenwirkung eines normalen Git-Kommandos.
Was die Quellen konkret belegen
Manifold nennt die Findings „GitSpawn“ und beschreibt betroffene Pfade in mehreren Agenten, darunter Goose, Claude Code, Qwen Code, Grok Build, Cursor, Codex und Hermes Agent. Nicht jeder Fall ist gleich: Manche Varianten nutzen core.fsmonitor, andere laut Manifold eine verwandte Git-Konfigurationssenke. Für Goose ist die Lage besonders gut belegt, weil die GitHub Advisory und der CVE-Eintrag öffentlich sind. Dort heißt es, goose review habe System-Git genutzt, um den Review-Diff zu sammeln, ohne attacker-controlled Git-Konfiguration zu strippen. Ein Repository mit [core] fsmonitor = <command> führe dadurch beim git diff HEAD einen Befehl auf dem Host aus – vor Modellaufruf, Prompt, Tool-Freigabe oder Trust-Prompt. Betroffen waren Versionen vor 1.44.0; 1.44.0 ist als Patch-Version genannt. GitHub bewertet den Fall mit CVSS 4.0 Score 7.0.
The Hacker News berichtet zusätzlich, dass OpenAI am selben Tag drei CVEs für Codex veröffentlichte, die zur gleichen Klasse gehören. In der öffentlichen Beschreibung zu CVE-2026-19592 wird der entscheidende Sicherheitsbruch ähnlich beschrieben: Der Helper laufe außerhalb der Codex-Command-Sandbox und ohne Approval-Prompt mit Benutzerrechten. Laut THN waren einige Produkte bereits gepatcht, während andere Fälle nach Manifold-Retest vom 1. September noch offen waren. Eine Massen-Ausnutzung ist dagegen nicht belegt. Der CISA-KEV-Katalog enthielt bei der Prüfung vom 2. September keine der im Artikel genannten CVEs; das reduziert nicht die technische Relevanz, begrenzt aber die Aussage zur realen Angriffslage.
Der ältere Cobalt-Red-Team-Beitrag von Dezember 2025 zeigt, dass FSMonitor-Missbrauch als Technik nicht neu ist. Neu ist die Breite der Agenten-Betroffenheit und der Zeitpunkt der Ausführung: Agentische Entwicklungswerkzeuge starten selbständig Hintergrundprozesse, bevor der Mensch überhaupt eine bewusste Sicherheitsentscheidung trifft.
Warum das für Unternehmen zählt
Der unmittelbare Schaden entspricht einem lokalen Code-Execution-Fall auf einem Entwicklerrechner. Das ist in modernen Umgebungen selten „nur lokal“. Entwickler-Workstations halten SSH-Keys, Cloud-Profile, Package-Registry-Tokens, GitHub- oder GitLab-Zugänge, Datenbank-Tunnel, .env-Dateien, API-Keys für LLM-Provider und zunehmend MCP- oder Agenten-Konfigurationen. In CI/CD- oder Agenten-Runnern kann derselbe Fehler Build-Secrets, Deployment-Rechte oder interne Quellcode-Repositories erreichen.
Besonders kritisch ist, dass der Angriff nicht wie ein typisches Prompt-Injection-Muster aussieht. Es muss kein README den Agenten überreden, keine bösartige Issue-Beschreibung interpretiert werden und kein Modell falsch entscheiden. Der Agent wird zur Ausführungsfläche, weil sein Hostprogramm Git automatisch startet. Damit gehört die Kontrolle nicht nur in Prompt-Filter, sondern in Prozess-, Dateisystem- und Tooling-Policy.
Praktische Gegenmaßnahmen
Erstens sollten Unternehmen untrusted Projektordner anders behandeln als normal geklonte Repositories. Code, der als Archiv oder Shared-Folder ankommt, gehört vor dem Öffnen in einem KI-Agenten geprüft. Mindestcheck: .git/config auf core.fsmonitor, ungewöhnliche core.hooksPath-Einträge, filter.*.process, diff.*.command, merge.*.driver und andere ausführbare Git-Konfigurationspfade untersuchen. Für FSMonitor reicht als erster Test im Repository: git config --get core.fsmonitor. Liefert der Befehl einen Pfad oder eine Kommandozeile, ist das ein Incident-Kandidat, kein Komfort-Feature.
Zweitens sollten Agenten und IDEs Git-Aufrufe härten. Hersteller sollten für Kontext-Gathering explizite Overrides setzen, etwa git -c core.fsmonitor=false status, und weitere Git-Konfigurationssenken auf eine Allowlist reduzieren. Nur core.fsmonitor zu blockieren reicht langfristig nicht, wenn andere Konfigurationswerte ebenfalls Helper oder Filter starten können.
Drittens braucht es Endpoint-Detection für Agenten-Prozessbäume. Wenn ein KI-Coding-Agent oder dessen Git-Subprozess plötzlich Shells, Interpreter, PowerShell, curl, ssh, Cloud-CLIs oder unbekannte Binaries startet, sollte das auffallen. Entwicklergeräte mit produktivem Cloud-Zugriff sind kein „low risk endpoint“ mehr.
Viertens sollten Secrets kurzlebiger und enger gescoped werden. Ein erfolgreicher GitSpawn-Angriff läuft mit Benutzerrechten; er kann nur stehlen, was dort vorhanden und gültig ist. Hardware-gebundene SSH-Keys, SSO mit Conditional Access, kurzlebige Cloud-Credentials, separate Profile für Kundenprojekte und keine dauerhaften LLM-Provider-Keys im Shell-Environment reduzieren den Schaden.
Grenzen der Bewertung
Nicht jede Organisation ist gleich betroffen. Wer Repositories ausschließlich über saubere Remote-Clones bezieht, untrusted Archive in isolierten VMs öffnet und Agenten ohne sensible Umgebung nutzt, hat ein deutlich kleineres Risiko. Auch ist bislang keine öffentliche Ausnutzung in freier Wildbahn belegt. Gleichzeitig ist die Schwachstelle leicht verständlich, demonstrierbar und trifft eine Arbeitsweise, die in vielen Teams informell verbreitet ist: „Schick mir mal den Projektordner.“
Fazit
GitSpawn ist ein gutes Beispiel dafür, warum KI-Agentensicherheit nicht bei Modellguardrails endet. Der riskante Teil ist hier nicht die Antwort des LLM, sondern die normale Vorarbeit des Tools: Kontext sammeln, Git starten, Workspace verstehen. Unternehmen sollten KI-Coding-Agenten deshalb wie privilegierte Developer-Tools behandeln. Fremde Repositories müssen eine Herkunfts- und Konfigurationsprüfung durchlaufen, Agenten-Git-Aufrufe brauchen harte Defaults, und Entwicklergeräte gehören in dieselbe Sicherheitslogik wie CI/CD-Runner. Die beste Sofortmaßnahme ist simpel: Keine zugeschickten Projektordner mit Agenten öffnen, bevor die lokale .git/config geprüft oder entfernt wurde.
Quellen: Manifold Security, „GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok“, 2. September 2026; The Hacker News, „Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code“, 2. September 2026; GitHub Security Advisory GHSA-r5pp-p5r8-466r / CVE-2026-72718; CVE.org CVE-2026-72718; Cobalt, „Red Team Technique: Exploiting Git FSMonitor for Initial Access“, 8. Dezember 2025; Git-Dokumentation zu core.fsmonitor.
