GitSpawn: Schadhafte .git/config-Dateien führen Code in KI-Coding-Agenten aus — noch bevor Sie reagieren können

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · KI/ML-Sicherheit, LLM-Agenten und KI-Produktivsysteme für US- und EU-Teams

Die kurze Antwort

Wie GitSpawn tatsächlich funktioniert

Gits core.fsmonitor-Konfigurationsschlüssel wurde als Performance-Optimierung eingeführt: Anstatt beim jedem git status den gesamten Arbeitsbaum zu scannen, kann Git die Prüfung an einen externen Dateisystem-Watcher delegieren. Der Wert des Schlüssels ist ein Shell-Befehl, den Git direkt startet, ihm die zuletzt geprüfte Zeit übergibt und eine Liste geänderter Pfade als Rückgabe erwartet. Entscheidend: Git hat keinen Mechanismus, um diesen Befehl zu validieren oder in einer Sandbox auszuführen — es führt die im Config stehende Zeichenkette mit den Rechten des aufrufenden Prozesses aus.

KI-Coding-Assistenten rufen routinemäßig git status, git diff und verwandte Befehle im Hintergrund auf, um den aktuellen Zustand eines Repositories zu verstehen, bevor sie Vorschläge generieren oder agentische Aktionen durchführen. Wenn ein solches Tool einen Projektordner mit einer präparierten .git/config öffnet, löst der allererste Git-Hintergrundaufruf den fsmonitor-Hook aus und führt die Payload des Angreifers aus. Der Workspace-Trust-Dialog des Agenten — der verhindern soll, dass schadhafte Workspace-Einstellungen Code ausführen — wird nach dem initialen Git-Kontext-Sammeln ausgelöst, nicht davor. Die Payload hat zu diesem Zeitpunkt bereits ausgeführt.

Im Manifold-Security-Proof-of-Concept sah der schadhafte Eintrag für einen flüchtigen Code-Reviewer aus wie eine gewöhnliche Performance-Tuning-Zeile. Der Forscher bestätigte, dass die Payload in jedem getesteten Agenten ausgeführt wurde, bevor der Nutzer irgendeinen Trust-Dialog bestätigte. Der Angriff verläuft lautlos: Der Agent zeigt weder einen Fehler noch eine Warnung; er lädt den Workspace weiter, als wäre nichts geschehen.

Wie die schadhafte Konfiguration zu Ihnen gelangt

Dies ist das wichtigste Detail für eine genaue Bedrohungsbewertung — und eines, das manche Sekundärberichte verwischt haben: Ein normales git clone reproduziert die Schwachstelle nicht. Beim Klonen eines Remote-Repositories holt Git die Objektdatenbank und erstellt den Arbeitsbaum neu, kopiert dabei jedoch nicht die .git/config des Remote auf die lokale. Die .git/config auf Ihrem Rechner wird von Git selbst neu erzeugt und enthält nur Ihre lokalen Einstellungen. Der schadhafte Eintrag kommt niemals an.

GitSpawn setzt voraus, dass das .git/-Verzeichnis intakt übertragen wird — mit der vom Angreifer kontrollierten .git/config bereits darin. Die realistischen Übertragungswege sind:

• ZIP-Archive und Tarballs. Wenn ein Projekt als komprimierter Ordner geteilt wird, ist das .git/-Verzeichnis standardmäßig enthalten. Ein Kollege, der per E-Mail ein „Starter-Repo“ als ZIP schickt, ein Anbieter, der ein Integrations-Template bereitstellt, oder ein internes Wiki, das einen verpackten Scaffold verlinkt — all das sind realistische Übertragungskanäle.
• Gemeinsame Netzlaufwerke und Cloud-Speicher. Das Kopieren eines Projektordners von einem Netzlaufwerk erhält .git/ intakt. Verbreitet in Teams, die ein gemeinsames NAS oder Cloud-Datei-Sync für interne Tools nutzen, anstatt ordentliche Versionskontrolle einzusetzen.
• USB oder externe Datenträger. In der modernen Entwicklung seltener, aber in luftdichten oder regulierten Umgebungen nach wie vor präsent.

Die praktische Konsequenz für Teams: Behandeln Sie jeden Projektordner, der als Archiv empfangen wurde, mit derselben Vorsicht wie eine ausführbare Datei — Quelle verifizieren, auf unerwartete .git/config-Einträge prüfen und nicht vertrauenswürdige Ordner in einer isolierten Container-Umgebung öffnen, bevor sie in einer KI-gestützten IDE geladen werden.

Welche Tools betroffen sind und was gepatcht wurde

Manifold Security testete sieben KI-Coding-Agenten und stellte fest, dass alle die fsmonitor-Payload ausgelösten. Offenlegungszeitplan, CVEs und Patch-Status zum 3. September 2026:

Manifold Security folgte dem Responsible-Disclosure-Prozess und informierte jeden Hersteller vor der Veröffentlichung. Anthropic, Block, OpenAI und Cursor reagierten und lieferten Patches vor dem öffentlichen Writeup aus. xAI, Alibaba und der Hermes-Agent-Maintainer stellten keinen Fix innerhalb des Offenlegungszeitraums bereit. Manifold bestätigte, dass ein sekundärer Ausführungspfad in Claude Code möglicherweise bis Version 2.1.252 offen bleibt — Anthropic hat dies anerkannt und verfolgt es separat.

Was das für US- und EU-Entwicklungsteams bedeutet

Die unmittelbare Botschaft ist klar: Aktualisieren Sie Ihre KI-Coding-Tools. Doch die weitreichende Implikation ist struktureller Natur — und sie ist relevant für jedes Team, das begonnen hat, KI-Agenten mit Schreibzugriff auf Code oder Dateisysteme zu betreiben.

KI-Coding-Assistenten wurden in erster Linie aus einer Produktivitätsperspektive heraus entwickelt: Wie schnell können sie Kontext sammeln, wie viele Operationen können sie automatisieren, wie nahtlos können sie in den bestehenden Entwickler-Workflow integriert werden? GitSpawn legt die Sicherheitskosten dieser Designpriorität offen. Die Agenten, die die fsmonitor-Payload ausführten, taten es, weil sie genau das taten, wozu sie gemacht sind: Git-Kontext automatisch und sofort sammeln, ohne den Entwickler zu belasten. Die Vertrauensgrenze — Workspace-Trust — war so konzipiert, dass sie schadhafte Workspace-Einstellungen abwehrt, nicht einen bewaffneten Git-Hook, der feuert, bevor der Workspace vollständig geladen ist.

Für Teams in regulierten Sektoren kommt eine zusätzliche Dimension hinzu. Ein Entwickler-Rechner, auf dem ein KI-Coding-Assistent mit Zugriff auf Quellcode, Umgebungsvariablen und Cloud-Zugangsdaten läuft, ist ein hochwertiges Ziel. Ein Angreifer, der über ein geteiltes Projekt-ZIP Code auf diesem Rechner ausführen kann, kann API-Schlüssel, Session-Tokens und lokale Credential-Stores lautlos exfiltrieren. Für Organisationen, die SOC 2, ISO 27001 oder der EU-NIS2-Richtlinie unterliegen, ist das kein hypothetisches Risiko — es ist eine Lücke im Kontroll-Inventar rund um Developer-Endpoint-Security, die die meisten Teams noch nicht auditiert haben.

Die dritte Implikation betrifft Teams, die KI-Agent-Systeme entwickeln und nicht nur nutzen. Wenn Ihr Produkt einen Agenten enthält, der auf vom Nutzer bereitgestellten Dateien oder Repositories operiert, gilt dieselbe Angriffsfläche für Ihre Nutzer. Ein Audit, wie Ihr Agent Git-Operationen behandelt, welche Hooks er respektiert und welches Vertrauensmodell den Zugriff auf Drittanbieter-Dateien regelt, ist jetzt eine sinnvolle Vorsichtsmaßnahme — bevor die nächste Variante dieser Klasse auftaucht. Genau diese Art von Überprüfung deckt ein Penetrationstest mit Fokus auf KI-Agent-Angriffsflächen ab.

DACH-Marktperspektive: Das BSI (Bundesamt für Sicherheit in der Informationstechnik) klassifiziert Supply-Chain-Angriffe auf Entwicklerwerkzeuge als Hochrisikovektor und empfiehlt Unternehmen, den Einsatz von KI-Coding-Agenten in ihre ISMS-Risikoanalyse nach ISO 27001 aufzunehmen. Für Organisationen im DACH-Raum, die unter die NIS2-Richtlinie fallen — Betreiber wesentlicher Dienste und wichtige Einrichtungen — ist GitSpawn ein konkretes Beispiel für die in §30 NIS2UmsuCG geforderten „geeigneten Maßnahmen zur Sicherung der Lieferkette“. Teams, die KI-Assistenten in CI/CD-Pipelines oder für Codegenerierung in regulierten Bereichen (Finanz, Gesundheit, kritische Infrastruktur) einsetzen, sollten die Schwachstelle als Anlass nehmen, ihr Developer-Endpoint-Security-Konzept zu prüfen — besonders da der Angriffsvektor (ZIP-Archive mit eingebetteten .git/-Verzeichnissen) in deutschen Mittelstandsprojekten weit verbreitet ist.

Was jetzt sofort zu tun ist

1. Claude Code auf 2.1.196 oder neuer aktualisieren. Führen Sie npm update -g @anthropic-ai/claude-code oder das Äquivalent für Ihre Installationsmethode aus. Beobachten Sie, ob ein Folge-Patch für den sekundären Pfad veröffentlicht wird.
2. Goose auf 1.44.0 oder neuer aktualisieren. Prüfen Sie Ihren Paketmanager oder die Goose-GitHub-Release-Seite auf den aktuellen Build.
3. OpenAI Codex auf 0.131.0 oder neuer aktualisieren. Führen Sie npm update -g @openai/codex aus oder aktualisieren Sie über die CLI.
4. Cursor aktualisieren. Installieren Sie ein Update vom August 2026 oder neuer über die Cursor-Website oder den In-App-Updater.
5. Grok Build, Qwen Code oder Hermes Agent nicht mehr mit nicht vertrauenswürdigen Projektordnern verwenden, bis Patches verfügbar sind. Wenn diese Tools im gesamten Team im Einsatz sind, geben Sie noch heute eine Richtlinienbenachrichtigung heraus.
6. Prüfen Sie, wie Projektordner geteilt werden. Wenn Ihr Team Starter-Repositories, Scaffold-Templates oder Client-Projekt-Archive als ZIP-Dateien verteilt, fügen Sie einen Schritt hinzu, der .git/-Verzeichnisse vor dem Verpacken entfernt — oder dokumentieren Sie, dass Empfänger die .git/config vor dem Öffnen in einer KI-gestützten IDE verifizieren müssen.
7. Einen Git-Hook-Check in Ihr Entwickler-Onboarding aufnehmen. Ein einfacher Lint-Schritt, der beim Projektöffnen unerwartete core.fsmonitor-, core.hooksPath- oder andere Erweiterungspunkte in .git/config markiert, ist in wenigen Minuten geschrieben und schließt diese Angriffskategorie für Ihr Team dauerhaft.

Häufig gestellte Fragen

Quellen

The Hacker News — Malicious Git Configs Can Make Claude Code, Cursor, and Codex Execute Arbitrary Commands
Manifold Security — AI Coding Agents Git Hijack: GitSpawn Research (Francisco Rosales)