GitSpawn: Präparierte Git-Ordner gefährden CLI-KI-Agenten
Manifold Security beschreibt unter dem Namen GitSpawn acht Schwachstellen in sieben CLI-KI-Coding-Agenten. Ein präparierter Projektordner samt .git-Verzeichnis kann beim automatischen Git-Aufruf Code mit den Rechten des angemeldeten Nutzers starten. Normales Klonen, Abrufen oder Aktualisieren eines Repositorys überträgt die nötige .git/config dagegen nicht.

Wer Claude Code, Goose, Hermes Agent, Qwen Code, Grok Build sowie Varianten bei Cursor oder Codex auf fremden Projektordnern startet, sollte diese Ordner vor dem ersten Agentenlauf prüfen. Der von Manifold Security als GitSpawn bezeichnete Angriff nutzt automatische Aufrufe wie git status oder git diff: Beim Aktualisieren des Git-Index kann core.fsmonitor aus .git/config einen präparierten Helper ausführen. Gesichert sind acht Schwachstellen in sieben untersuchten Agenten, vier davon zum Veröffentlichungszeitpunkt ungepatcht. Unsicher bleiben mangels vollständiger Herstellerangaben darüber hinausgehende Patchstände und betroffene Versionen.
Dringend ist die Prüfung vor allem dort, wo vollständige Projektordner samt .git über ZIP-Archive, Shared Drives, synchronisierte Ordner oder USB-Datenträger übernommen werden. Ein normales git clone, git fetch oder git pull überträgt die feindliche .git/config nicht. Admins sollten verdächtige Ordner isoliert untersuchen, .git/config vor dem Agentenstart auf core.fsmonitor prüfen, deaktivieren, Updates installieren und Agenten nur mit minimalen Nutzerrechten betreiben.
Was ist GitSpawn?
Manifold Security fasst unter dem Namen GitSpawn eine Schwachstellenklasse zusammen, die eine unerwartete Vertrauensgrenze zwischen KI-Coding-Agent und Git ausnutzt. Agenten wollen beim Öffnen eines Projekts schnell verstehen, welche Dateien geändert wurden und welcher Zustand im Repository vorliegt, und rufen dafür selbstständig Git-Befehle auf, noch bevor ein Nutzer eine konkrete Änderung freigegeben hat. Genau an dieser Kontextsammlung setzt der Angriff an: Ein Angreifer präpariert den vollständigen Projektordner samt normalerweise verborgenem Verzeichnis .git. In dessen lokaler Konfigurationsdatei kann core.fsmonitor auf einen ausführbaren Helper verweisen, der beim Index-Update durch git status oder git diff gestartet wird.
Die Ausführung entsteht damit nicht durch einen bösartigen Prompt oder eine vom Agenten vorgeschlagene Shell-Aktion, sondern tiefer in der Werkzeugkette, wenn Git die lokale Repository-Konfiguration auswertet.
So verläuft der Angriffspfad
- Angreifer präpariert einen Projektordner samt
.git. - In
.git/configwirdcore.fsmonitorauf einen kontrollierten Helper gesetzt. - Der Ordner gelangt als ZIP, über Shared Drive, Sync-Ordner oder USB zum Ziel.
- Nutzer öffnet den Ordner mit einem betroffenen Agenten.
- Der Agent ruft zur Kontextsammlung automatisch
git statusodergit diffauf. - Git aktualisiert den Index, liest die Konfiguration, startet den File-System-Monitor.
- Der Helper läuft mit Nutzerrechten, ohne Bestätigung durch die Freigabelogik des Agenten.
Eine Agenten-Sandbox oder Rückfrage vor Shell-Befehlen schützt hier nicht, weil ein bereits erlaubtes Werkzeug selbst den externen Prozess startet. Der Code läuft außerhalb der Sandbox, ohne Agenten-Freigabe, mit Rechten des angemeldeten Kontos.
Welche Produkte wurden untersucht?
Die Berichte nennen sieben CLI-KI-Agenten beziehungsweise Produktvarianten: Claude Code, Goose, Hermes Agent, Qwen Code, Grok Build sowie Varianten bei Cursor und Codex. Insgesamt ordnet Manifold Security diesen Produkten acht Schwachstellen zu.
| Produkt oder Variante | Im Zusammenhang mit GitSpawn genannt | Veröffentlichter Stand |
|---|---|---|
| Claude Code | Ja | Kein darüber hinausgehender Patchstand hier belegt |
| Goose | Ja, CVE-2026-72718 | Als behoben gemeldet |
| Hermes Agent | Ja, laut Zweitquelle CVE-2026-71963 | Kein darüber hinausgehender Patchstand hier belegt |
| Qwen Code | Ja | Kein darüber hinausgehender Patchstand hier belegt |
| Grok Build | Ja | Kein darüber hinausgehender Patchstand hier belegt |
| Cursor-Variante | Ja | Als gepatcht gemeldet |
| Codex-Variante | Ja | Als gepatcht gemeldet |
Vier der acht Schwachstellen waren bei Veröffentlichung ungepatcht. Verantwortliche sollten den Stand ihres eingesetzten Agenten direkt prüfen, statt aus der Gesamtzahl zu schließen.
Warum normales Klonen nicht reicht
Git behandelt .git anders als versionierte Projektdateien. Ein übliches git clone übernimmt Commits, Referenzen und Arbeitsdateien, aber nicht die vom Absender gesetzte repository-lokale .git/config. Auch git fetch und git pull transportieren diese fremde Konfiguration nicht ins lokale Repository. Riskant sind stattdessen Übergaben, bei denen der gesamte Ordner unverändert kopiert wird, etwa entpackte Archive mit enthaltenem .git, freigegebene Projektverzeichnisse, Cloud-Synchronisationen, kopierte Entwicklerprofile, Support-Pakete oder Wechseldatenträger. Solche Komplettordner werden in Entwicklung, Support und Incident Response häufig weitergereicht, weshalb diese Einschränkung kein Grund zur Entwarnung ist.
Wie kritisch ist das für Unternehmen?
In der passenden Umgebung ist das Risiko hoch: Codeausführung als angemeldeter Nutzer ist möglich, die Freigabe des KI-Agenten wird umgangen. Der Angriff ist aber nicht mit beliebiger Codeausführung durch den bloßen Besuch eines öffentlichen Repositorys gleichzusetzen, sondern setzt einen präparierten Komplettordner voraus.
Besonders relevant ist GitSpawn für Teams, die externe Codebeispiele, Kundenprojekte, Bewerbungsaufgaben oder Analysepakete übernehmen, vor allem wenn Entwicklerkonten Zugriff auf SSH-Schlüssel, Paketregistrierungen, Cloud-Zugänge oder Produktionswerkzeuge haben. Wie bei anderen Risiken durch Erweiterungen und Agentenfähigkeiten zeigt auch ein manipulierter KI-Agent-Skill, dass vorgelagerte Vertrauensprüfungen wichtiger werden. Belege für eine aktive Ausnutzung oder eine bestimmte Angreifergruppe nennen die verwendeten Quellen nicht. Unternehmen sollten gezielt prüfen und härten, die Meldung aber nicht als Nachweis eines Massenangriffs werten.
Was sollten Admins und Entwickler jetzt tun?
- Projektquellen erfassen: Feststellen, welche Arbeitsordner aus ZIP, Shared Drive, Sync-Dienst oder USB stammen.
- Git-Konfiguration prüfen: Vor Agentenstart
.git/configöffnen, nachcore.fsmonitorund unbekannten Helper-Pfaden suchen. - Fsmonitor deaktivieren: In nicht vertrauenswürdigen Kopien
core.fsmonitorentfernen, bevor ein Agent im Ordner arbeitet. - Isoliert analysieren: Unbekannte Ordner in getrennter VM oder abgeschottetem Konto untersuchen, ohne produktive Zugangsdaten.
- Sauber neu klonen: Bei vertrauenswürdiger Remote-Quelle frisches
git clonestatt Komplettordner übernehmen. - Agenten aktualisieren: Herstellerupdates installieren. Cursor/Codex gelten als gepatcht, Goose (CVE-2026-72718) als behoben.
- Rechte begrenzen: Agenten nicht mit Adminrechten betreiben, Zugriffe auf SSH-Schlüssel, Cloud-Zugänge und Produktionssysteme minimieren.
- Geheimnisse trennen: Zugänge nicht dauerhaft in Umgebungsvariablen oder frei lesbaren Dateien bereitstellen.
- Übergabeprozess ändern: Projektordner samt
.gitals aktive Inhalte behandeln, nicht als passive Archive. - Teams informieren: Prüfung vor Agentenstart Pflicht.
Least Privilege begrenzt nicht die Ausführung selbst, kann aber deren Folgen reduzieren. Für administrative Zugänge empfiehlt sich eine saubere Schlüsselverwaltung, siehe die Anleitung zur SSH-Key-Authentifizierung unter Linux und Windows. Schlüssel sollten nicht unnötig in Agentenumgebungen erreichbar sein.
Was der Fall über Agenten-Sandboxen zeigt
GitSpawn zeigt indirekte Werkzeugausführung: Ein erlaubtes Programm lädt Konfigurationsdateien oder Helper und startet dadurch Code außerhalb der erwarteten Kontrollschicht. Der Vorfall um ein gemeinsam genutztes schwarzes Brett für OpenAI-Agenten zeigt ebenfalls, wie Datenübergaben zwischen Agenten und externen Systemen neue Sicherheitsgrenzen schaffen. Eine Freigabeoberfläche schützt daher nicht ausreichend, wenn sie nur direkte Agentenaktionen erfasst statt der gesamten Prozesskette aus Ordnerherkunft, Konfiguration, Rechten und Geheimnissen.
Gesicherte Fakten und offene Punkte
- Gesichert: acht Schwachstellen in sieben untersuchten CLI-KI-Agenten unter dem Namen GitSpawn.
- Gesichert: automatische Git-Aufrufe und ein repository-lokaler
core.fsmonitor-Helper als technischer Kern. - Gesichert: der Helper läuft als angemeldeter Nutzer außerhalb der Agenten-Sandbox und ohne Agenten-Freigabe.
- Gesichert: normale Abläufe mit
git clone,git fetchundgit pullübertragen die feindliche.git/confignicht. - Gesichert: ein vollständiger Ordner samt
.gitist nötig, etwa aus ZIP, Shared Drive, Sync-Ordner oder USB-Medium. - Als behoben gemeldet: Goose unter CVE-2026-72718 sowie die untersuchten Varianten bei Cursor und Codex.
- Hermes Agent wird in einer Zweitquelle mit CVE-2026-71963 genannt.
- Offen: genaue betroffene Versionsbereiche und darüber hinausgehende Patchstände.
- Nicht belegt: aktive Ausnutzung, eine konkrete Angreifergruppe oder eine breit angelegte Kampagne.
Passende Anleitungen auf S-EDV
- Wie eine gefälschte KI-Agent-Skill alle Security-Scanner passierte
- OpenAI-Agenten und der Hugging-Face-Vorfall: Was Admins daraus lernen
- SSH-Key-Authentifizierung unter Linux und Windows einrichten