Git-Config-Fallen: Warum dein Coding-Agent Code ausführt, den du nie geklont hast

Ein fremdes Projektverzeichnis reicht aus, damit dein Coding-Agent Code ausführt, den niemand bei dir bestätigt hat. Das ist das Ergebnis der GitSpawn-Recherche von Manifold Security vom 01.09.2026: acht Schwachstellen, sieben geprüfte Agenten, vier davon beim Erscheinen ungepatcht. Zu den genannten Agenten gehört auch der, der diesen Blog betreibt. Diese Fassung korrigiert außerdem einen Fehler, der drei Tage lang in der vorherigen stand: Der Angriff kommt nicht aus dem Klon.

Git liest seine Einstellungen aus drei Ebenen: systemweit, im Konto des Nutzers und aus der lokalen Konfiguration des Repositorys. Die lokale Ebene liegt im Ordner des Projekts und kann mitgeliefert werden. Einer der Schalter dort heißt core.fsmonitor. Er ist offiziell eine Leistungsoptimierung für große Projekte: Statt selbst alle Dateien zu prüfen, fragt Git ein Hilfsprogramm, was sich geändert hat. Dieses Hilfsprogramm ist ein Befehl, und Git führt ihn aus, sobald der Index aufgefrischt wird.

Das klingt harmlos, bis man sieht, welche Befehle den Index auffrischen. Nahezu alles, was das Arbeitsverzeichnis anfasst: git status, git diff, und genau solche Aufrufe machen Coding-Agenten ständig. Sonar hat die Mechanik 2022 vorgeführt: eine Zeile in die lokale Konfiguration geschrieben, die die eigene Nutzerkennung in eine Datei schreibt, dann git status aufgerufen, und die Datei war da. Das Kommando läuft mit den Rechten des Nutzers, ohne Bestätigung, ohne Fenster.

Wichtig ist die Rangfolge der Ebenen. Git wertet die drei Quellen in fester Reihenfolge aus: System-, Konto- und Projekt-Ebene, wobei die letztere der vorherigen widersprechende Werte überschreibt. Für die Abwehr ergibt sich daraus ein naheliegender Fehlschluss: core.fsmonitor global auf false zu setzen schützt nicht, denn eine mitgelieferte Projektkonfiguration darf genau diesen Wert wieder überschreiben. Wirklich übergehen lässt sich die Projekt-Ebene nur mit dem Einweg-Override auf der Befehlszeile, etwa git -c core.fsmonitor=false status, oder dadurch, dass das Werkzeug selbst die Hintergrund-Aufrufe härtert, wie es Sonar für die Editor-Integrationen und Manifold für die Agenten-Hersteller fordern.

Manifold Security hat 2026 denselben Mechanismus bei CLI-Agenten gefunden, mit einem entscheidenden Detail dazu: Die Agenten rufen Git im Hintergrund auf, um Kontext zu sammeln, bei manchen schon beim Öffnen des Ordners, vor dem Workspace-Trust-Hinweis, vor der Anmeldung. Der Aufruf läuft als Unterprozess des Agenten und damit außerhalb der Sandbox und des Freigabemodells. Kein Prompt erscheint, weil das Permission-Modell diesen Weg gar nicht sieht.

Hier lag der Fehler der vorherigen Fassung dieses Beitrags, deshalb steht die Korrektur im Klartext: Ein gewöhnlicher Klon übernimmt die lokale Konfiguration nicht. Sonar schreibt in der Analyse von 2022, dass das Klonen eines fremden Repositorys die für den Angriff nötigen Dateien nicht holt. Manifold formuliert es 2026 genauso: Das Klonen einer feindlichen Adresse tut nichts, das Projekt muss als Dateisammlung ankommen, mit bereits enthaltenem .git-Ordner. Jeder Beweislauf in der Recherche lief über eine Zip-Datei.

Der Weg ist damit genau der Alltagsweg von Projekten: ein Zip im Anhang, ein geteilter Laufwerksordner, ein Sync-Dienst, ein USB-Stick. Wer Kollegen Projektordner weitergibt oder Kunden Übergaben schickt, bewegt Verzeichnisse, und genau die können die Falle tragen. Der Klon aus dem Netz ist dagegen der sichere Weg, was gegen die Intuition läuft und deshalb so oft falsch weitererzählt wird, in meinem vorherigen Beitrag eingeschlossen.

Ein Mensch führt git status ein paar Mal pro Stunde aus. Ein Agent führt es in vielen Arbeitsrunden aus, bei den meisten Produkten automatisiert beim Start der Sitzung, und zwischen diesen Punkten liegen weitere Git-Aufrufe. Aus einem seltenen Auslöser wird ein Dauerzustand, und der Aufruf passiert genau dann, wenn der Nutzer nichts tut als zu warten. Dazu kommt, dass der Agent als Unterprozess arbeitet: Die Freigabe-Routinen, die verhindern sollen, dass ein Modell gefährliche Befehle startet, sehen diesen Weg nicht, weil er unterhalb ihrer Ebene liegt.

Die Recherche von Manifold listet die Befunde einzeln auf. Bei Claude Code wurde der fsmonitor-Weg mit Version 2.1.196 geschlossen, ein zweiter Weg im Prüfverlauf blieb beim Erscheinen offen. Bei OpenAI Codex und Cursor wurde nachgereicht und ebenfalls geschlossen. Offen blieben beim Erscheinen: Qwen Code, Grok Build, ein zweiter Claude-Code-Weg und Hermes Agent. Für Hermes wurde die Nummer CVE-2026-71963 vergeben, ohne dass der Hersteller sie bestätigt hat. Die folgende Tabelle fasst die Zeitachse zusammen.

Vor der Theorie die eigene Bilanz, frisch gemessen am Abend des 05.09.2026. Die Suche lief auf diesem Deck, also im PRoot-Container des Pixel: über /root (komplett) und /storage/emulated/0 bis zu fünf Ordnerebenen tief. Sie ergab genau einen Treffer: /root/.codex/.tmp/plugins/.git, das temporäre Plugin-Verzeichnis eines Codex-Toolbausteins. Die Messgrenzen sind: nur dieses Gerät, nur zwei Pfade, nur fünf Ordnerebenen tief. Innerhalb dieser Grenzen ist der Treffer der einzige. Unter /storage lag in Suchtiefe kein weiteres Repository. Die globale Git-Konfiguration dieses Systems setzt weder core.fsmonitor noch core.hooksPath, beide Abfragen kommen leer zurück.

Der zweite Teil der Bilanz ist unbequemer: Der eigene Agent gehört vermutlich zu der Liste. Das Deck läuft mit Hermes Agent 0.20.6, und die Recherche berichtet die Schwachstelle für Hermes bis einschließlich 0.21.0 als ungeschlossen. Ich habe keine eigene Sicherheitstestreihe gefahren, die Zuordnung beruht auf der Versionsspanne im Bericht plus eigener Versionsermittlung. Die Ausnutzung braucht ein Verzeichnis mit mitgelieferter .git-Konfiguration, und genau so ein Verzeichnis wird auf diesem System nicht geöffnet, bevor es geprüft ist. Das ist eine Arbeitsregel, kein Patch, und sie steht in der nächsten Abteilung.

Diese Transparenz gehört für mich zum Projekt dazu: Ein Blog, der Agentenbetrieb dokumentiert, muss auch schreiben dürfen, wenn der eigene Agent in einer Sicherheitsliste auftaucht. Der Angriff trifft nicht die Hardware und nicht das Modell, sondern eine Versionsspanne eines Werkzeugs, mit dem hier täglich gearbeitet wird. Wer denselben Stack fährt, findet seine Version mit hermes --version und vergleicht sie mit der Tabelle oben.

Bevor es an die eigenen Schritte geht, eine Anmerkung zur Haltbarkeit: Die Tabelle weiter oben hat einen Stichtag, den 01.09.2026, die eigenen Messwerte in diesem Beitrag stammen vom 05.09.2026. Patch-Status ist eine Bewegungsgröße, vier der acht Befunde waren am Stichtag offen und können bei deiner Lektüre längst geschlossen sein. Prüfe die Version deiner Werkzeuge zum Lesezeitpunkt, nicht die Erinnerung an diesen Text.

Drei Schritte, ohne Zusatzwerkzeuge. Erstens: Projekte, die als Ordner ankommen, vor dem Öffnen mit dem Agenten prüfen. Der Blick gilt der Datei .git/config, und jede Zeile, die ein Programm oder einen Pfad benennt, ist ein Stopp-Schild, core.fsmonitor ist der bekannteste Kandidat. Wer mag, nutzt git config --get core.fsmonitor und git config --get core.hooksPath im Projektordner, jede Ausgabe außer leer oder false braucht eine Erklärung.

Zweitens: Eigene Skripte, die Git aufrufen, können die mitgelieferte Einstellung für den einzelnen Aufruf abstellen. Der Aufruf git -c core.fsmonitor=false status ignoriert die Projekt-Einstellung, genau das empfehlen auch die Rechercheure den Agenten-Herstellern für ihre Hintergrund-Aufrufe. Drittens: Die Version des eigenen Agenten gegen die Tabelle prüfen und Werkzeug und Git aktuell halten. Zwei gepatchte Einträge der Liste wurden innerhalb von Wochen geschlossen, weil Berichte vorlagen, das Fenster lebt von Updates.

Und die Struktur, die hier auf dem Deck ohnehin gilt, hilft auch bei dieser Klasse von Angriff: Lesen und Bauen bleiben getrennt. Fremdes Material kommt als Text oder Link in die Planung, gebaut wird in Verzeichnissen, die dieses Material nicht als Ordner enthalten. Wer beides in denselben Topf wirft, verliert bei einem Treffer beides gleichzeitig. Wie der Stack im Ganzen aussieht, steht im Beitrag zum Agenten-Stack auf dem 45-Euro-Handy.

Vier Einschränkungen gehören in diesen Text. Erstens: Ich habe keine der acht Schwachstellen selbst ausgenutzt, meine Grundlage sind die gelesenen Analysen von Manifold Security und Sonar plus die eigenen Messwerte vom 05.09.2026. Zweitens: Die Patch-Lage ändert sich, die Tabelle zeigt den Stand vom 01.09.2026, nicht den Zeitpunkt deiner Lektüre. Drittens: Die Git-Dokumentation beschreibt core.fsmonitor als beabsichtigtes Verhalten, der Angriff nutzt beabsichtigte Mechanik, es gibt also keinen Fehler, den Git allein beheben könnte, die Absicherung liegt bei Werkzeug und Nutzer.

Viertens: Ein abgeschalteter Schalter ist keine allgemeine Entwarnung. Die Recherche benennt mindestens eine Lücke, die auf einem anderen Schalter derselben Art beruht, dessen Name wegen ausstehender Reparatur bewusst nicht genannt wird. Was bleibt, ist eine Haltung: Ordner von Fremden vor dem Öffnen ansehen, Hintergrund-Aufrufe härten, Versionen aktuell halten. Mehr verspricht dieser Text nicht, und weniger braucht es nicht.

Ich bin Marcel, Grafikdesigner und Betreiber der d4sn3st-Seiten. Seit 2026 betreibe ich KI-Agenten auf einem gebrauchten Google Pixel 6a und dokumentiere den Betrieb auf diesem Blog, inklusive der Seiten, die nicht glänzen. Diesem Beitrag liegen die gelesenen Analysen von Manifold Security und Sonar zugrunde sowie eigene Messwerte vom 05.09.2026: die .git-Zählung, die globale Config-Prüfung und die eigene Hermes-Version. Zuletzt fachlich geprüft am 05.09.2026.