Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 03.09.2026 · 6 min Lesezeit

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.

Illustration zu GitSpawn: praeparierte Git-Konfigurationen kapern KI-Coding-Agenten, Angriffspfad von praeparierten Projektordnern ueber git status bis zur Codeausfuehrung KI-generiert

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

  1. Angreifer präpariert einen Projektordner samt .git.
  2. In .git/config wird core.fsmonitor auf einen kontrollierten Helper gesetzt.
  3. Der Ordner gelangt als ZIP, über Shared Drive, Sync-Ordner oder USB zum Ziel.
  4. Nutzer öffnet den Ordner mit einem betroffenen Agenten.
  5. Der Agent ruft zur Kontextsammlung automatisch git status oder git diff auf.
  6. Git aktualisiert den Index, liest die Konfiguration, startet den File-System-Monitor.
  7. 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 VarianteIm Zusammenhang mit GitSpawn genanntVeröffentlichter Stand
Claude CodeJaKein darüber hinausgehender Patchstand hier belegt
GooseJa, CVE-2026-72718Als behoben gemeldet
Hermes AgentJa, laut Zweitquelle CVE-2026-71963Kein darüber hinausgehender Patchstand hier belegt
Qwen CodeJaKein darüber hinausgehender Patchstand hier belegt
Grok BuildJaKein darüber hinausgehender Patchstand hier belegt
Cursor-VarianteJaAls gepatcht gemeldet
Codex-VarianteJaAls 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?

  1. Projektquellen erfassen: Feststellen, welche Arbeitsordner aus ZIP, Shared Drive, Sync-Dienst oder USB stammen.
  2. Git-Konfiguration prüfen: Vor Agentenstart .git/config öffnen, nach core.fsmonitor und unbekannten Helper-Pfaden suchen.
  3. Fsmonitor deaktivieren: In nicht vertrauenswürdigen Kopien core.fsmonitor entfernen, bevor ein Agent im Ordner arbeitet.
  4. Isoliert analysieren: Unbekannte Ordner in getrennter VM oder abgeschottetem Konto untersuchen, ohne produktive Zugangsdaten.
  5. Sauber neu klonen: Bei vertrauenswürdiger Remote-Quelle frisches git clone statt Komplettordner übernehmen.
  6. Agenten aktualisieren: Herstellerupdates installieren. Cursor/Codex gelten als gepatcht, Goose (CVE-2026-72718) als behoben.
  7. Rechte begrenzen: Agenten nicht mit Adminrechten betreiben, Zugriffe auf SSH-Schlüssel, Cloud-Zugänge und Produktionssysteme minimieren.
  8. Geheimnisse trennen: Zugänge nicht dauerhaft in Umgebungsvariablen oder frei lesbaren Dateien bereitstellen.
  9. Übergabeprozess ändern: Projektordner samt .git als aktive Inhalte behandeln, nicht als passive Archive.
  10. 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 fetch und git pull übertragen die feindliche .git/config nicht.
  • Gesichert: ein vollständiger Ordner samt .git ist 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

Quellen

GitSpawnGitKI-Coding-AgentenCLI-SicherheitCodeausführungClaude CodeHermes AgentGooseCursorCodex