Am Freitagnachmittag packt ein Kollege ein Projekt als Zip zusammen und schreibt dir: „Schau dir mal diesen Bug an.“ Du entpackst sie, ziehst den Ordner in Hermes und beginnst, deine erste Anweisung zu tippen – doch in diesen wenigen Sekunden ist auf deinem Rechner bereits Code gelaufen, der nicht von dir stammt, mit deinen Rechten. Kein Popup, kein Approval-Prompt, nichts auf dem Bildschirm. Das ist keine Filmhandlung, sondern eine reale Schwachstellen-Klasse, die die Sicherheitsfirma Manifold Security am 1. September unter dem Namen GitSpawn offengelegt hat und die fast jedes gängige KI-Coding-Tool betrifft – Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build und Hermes Agent. Die gute Nachricht: Hermes hat den Fix am 2. September gemerged (PR #101483, aktuell auf main).

So funktioniert der Angriff: Das geöffnete Repository „führt“ einen Befehl für dich aus

KI-Coding-Tools – Hermes eingeschlossen – führen beim Start ein paar git-Befehle aus, um herauszufinden, wo sie sind: auf welchem Branch du dich befindest, welche Dateien sich geändert haben. Diese Kontextsammlung läuft automatisch ab, vor jedem Prompt, vor jedem Tool-Call, vor jeder Workspace-Trust-Bestätigung. Der Agent muss schließlich wissen, wo er ist, bevor er irgendetwas tun kann.

Das Problem steckt in einem Git-Performance-Feature: core.fsmonitor. Bei großen Repositories will git nicht jede Datei scannen, um festzustellen, was sich geändert hat – stattdessen lässt es dich ein Hilfsprogramm konfigurieren, das diese Frage beantwortet. Git führt dieses Programm bei jedem index refresh aus – und Befehle wie git status und git diff lösen einen index refresh aus.

Der Haken: git liest diese Einstellung aus dem eigenen .git/config des Repositories. Ein bösartiges Repository kann also Folgendes mitbringen:

[core]
    fsmonitor = /tmp/pwn.sh

Mehr musst du nicht tun, als das Repository zu öffnen – ohne ein einziges Wort –, und schon sorgt das git status, das Hermes automatisch ausführt, dafür, dass git /tmp/pwn.sh ausführt: als dich, mit deinen Rechten, außerhalb der Sandbox und ohne Approval-UI. Ein Angreifer bekommt damit mehr als „kann Code ausführen“: deine SSH-Keys, Cloud-Zugangsdaten, Shell-Tokens und einen Fuß in der Tür auf der gesamten Maschine.

core.fsmonitor ist nur einer der Execution Sinks dieser Klasse. Der Report von Manifold behandelt außerdem core.hooksPath (Hooks beim Checkout), Pager-/Editor-/Credential-Einstellungen und die heimtückischeren, über .gitattributes gekoppelten Diff-Driver ([diff "x"] command= / textconv=, ausgeführt, sobald ein Diff gerendert wird). Die letzte Variante ist die fieseste: Der Angreifer bestimmt den Namen des Drivers, daher kann man sie nicht über Umgebungsvariablen-Overrides abdecken – nur Kommandozeilen-Flags können sie abschalten.

Wie es sich verbreitet: Warum git clone sicher ist und Zip-Dateien nicht

Diese Schwachstelle hat eine kontraintuitive Eigenschaft: Ein bösartiges Repository über das Netzwerk zu klonen ist sicher. git überträgt bei clone/fetch/pull niemals .git/config – das ist eine private Datei deines lokalen Repositories, und die Version des entfernten Repositories ist für dich irrelevant.

Gefährlich ist dagegen ein Repository, das als Dateien ankommt: als Verzeichnis mit intaktem .git-Ordner. Eine geteilte Zip-Datei, ein synchronisierter Cloud-Ordner, ein USB-Stick, ein Projektverzeichnis, das ein Kollege direkt kopiert hat – jede dieser Varianten erhält das .git/config des Absenders. In Manifolds Proofs of Concept kam eine Zip-Datei zum Einsatz.

Die Faustregel ist also einfach: Sei misstrauisch gegenüber „verpackten Projektordnern“, die dir jemand anderes in die Hand drückt, bevor du sie mit einem KI-Tool öffnest; was du per git clone beziehst, ist von Natur aus sicher.

Reaktion der Branche: Acht Findings, vier bei Offenlegung noch ungepatcht

Manifold Security hat den vollständigen Report am 1. September veröffentlicht – acht Findings in sieben AI-Coding-Tools. Stand bei Veröffentlichung:

Tool	Status
Claude Code (fsmonitor-Pfad)	Behoben (2.1.196)
Claude Code (ultrareview-Pfad)	Bei Offenlegung ungepatcht (auf 2.1.252 weiterhin verwundbar)
Goose	Behoben (1.44.0, CVE-2026-72718)
Codex / Cursor	Behoben
Hermes Agent	Bei Offenlegung ungepatcht – Fix am 2. September gemerged
Qwen Code / Grok Build	Bei Offenlegung ungepatcht

Die Berichterstattung von The Hacker News vom 2. September führte Hermes noch als „Fix steht aus“ – doch Nous Research hat den Fix noch am selben Tag in main gemerged, einen Tag jünger als die Meldung.

Hermes’ Fix: „bare git“ wird zu „sanitized git“

Der Fix (PR #101483, Commit f6234d00c5) ist konzeptionell einfach: Jede git-Probe, die Hermes selbst anstößt, läuft jetzt in einer bereinigten Umgebung, die die eigene Konfiguration des Repositories vollständig ignoriert.

Zwei Verteidigungsebenen:

Ebene 1 – Umgebungsbereinigung (noninteractive_git_env()). Alle automatischen Probes verwenden jetzt standardmäßig eine „non-interactive git environment“, die core.fsmonitor, core.hooksPath, Pager, Editor und Credential-Helper über GIT_CONFIG_* auf träge Werte festlegt und globale sowie System-Konfiguration ignoriert. Wenn git status den Index aktualisiert, gibt es kein „vom Repository vorgegebenes Hilfsprogramm“ mehr, das ausgeführt werden könnte. Zu den abgedeckten Aufrufstellen gehören der Workspace-Kontext-Snapshot (coding_context), der Projektbaum-Aufbau des Gateways, die @diff-/@staged-Kontextreferenzen, der Goal-Gate-Fingerprint und das worktree add beim Start mit -w.

Ebene 2 – Kommandozeilen-Flags (harden_git_argv()). Umgebungsvariablen erreichen die über .gitattributes gebundenen Driver nicht (der Angreifer benennt den Driver, du kannst ihn also nicht aufzählen), deshalb injiziert Hermes bei den Diff-rendering-Subcommands – diff, show, log, blame – jetzt --no-ext-diff --no-textconv und schneidet damit beide Ausführungspunkte ([diff "x"] command= und textconv=) auf Kommandozeilen-Ebene ab.

Mit dem Fix wird eine End-to-End-Regressionssuite mit echtem git ausgeliefert: Sie präpariert ein Repository mit bösartiger Konfiguration und stellt per Assertion sicher, dass keiner der automatischen Pfade fsmonitor, Hooks, External-Diff oder textconv ausführt.

Was du jetzt tun solltest

1. Kenne deine Version: Der Fix ist am 2. September auf main gelandet und steckt noch in keinem offiziellen Release (das neueste Release, v0.21.0, erschien am 31. August – vor dem Fix). Wer vom ersten Tag an geschützt sein will, verfolgt main oder wartet auf das nächste Patch-Release; fang in jedem Fall schon jetzt mit den Gewohnheiten unten an.
2. Sei misstrauisch gegenüber Repositories in „Dateiform“: Prüfe Zip-Dateien, synchronisierte Ordner und per USB kopierte Projektverzeichnisse, bevor du sie öffnest. Repositories, die du per git clone beziehst, brauchen diese Sorge nicht.
3. Prüfe ein erhaltenes Projekt selbst, bevor du es an Hermes übergibst:

cd path/to/suspicious-project
git config --get core.fsmonitor      # output here = be alert
git config --get core.hooksPath
grep -nE "command *=|textconv *=" .git/config

4. Öffne keine Session direkt in einem verdächtigen Verzeichnis: Musst du den Code unbedingt ansehen, klone zuerst eine saubere Kopie (git clone) und gib Hermes diese.

Dieser Vorfall gehört mit dem SSH-Config-Approval-Gate, über das wir früher berichtet haben, zu derselben Lektion: Die Low-Level-Befehle, die ein KI-Tool automatisch ausführt, müssen davon ausgehen, dass ihre Eingabe nicht vertrauenswürdig ist. Hermes’ Fix zieht selbst den frühesten und unsichtbarsten Schritt – die Kontextsammlung – in die Trust-Boundary hinein. Wo du nichts siehst, geht Hermes jetzt davon aus, dass das Repository der Feind sein könnte.