Skip to main contentClaim $5 in free credit — one-time, per account. Claim $5 free
Krova CloudKrova Cloud
AI Code Sandboxing

GitSpawn: The Git Config That Runs Before Your Agent Asks

One line in a repository's git config runs attacker code before your coding agent's first approval prompt. GitSpawn patches fixed four of eight paths.

6 min read
Share
GitSpawn: The Git Config That Runs Before Your Agent Asks: a frosted folder-cube with one bright teal config line and a spark jumping to an agent cube beside an open gate

GitSpawn is the name Manifold Security gave to a class of eight flaws where a repository's own git config runs attacker code on your machine. One line under [core] naming fsmonitor is enough. The payload fires on the agent's first git status, outside the sandbox and before any approval prompt, because git trusts the folder it was handed. Four of the eight findings were still unpatched at publication.

Manifold published the research on 1 September 2026 across seven agents: Claude Code, Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build.

GitSpawn executes your git config, not the model

The sink is a legitimate feature. core.fsmonitor tells git which command to run to detect changed files in large repositories, so any operation that refreshes the index executes it. That includes git status and git diff, the two most boring commands in the tool. A poisoned repository needs exactly one line in .git/config, and the named command runs as your user, not as the agent.

Other keys behave the same way. core.sshCommand, filter drivers and textconv filters all name programs git will execute during ordinary operations. Manifold's write-up groups these as execution sinks, and the agent never sees them: the harness calls git for context, and git obeys the folder it was pointed at.

The sandbox and the approval prompt miss it together

Two controls fail at once, for different reasons. The sandbox surrounds the agent's own commands, while git runs outside that boundary as a trusted binary on your host. The approval prompt gates what the agent decides to do, and this command is never the agent's decision. It belongs to git, made before the model sees anything at all.

That ordering is the whole trick. The payload lands before the first token of reasoning, so no prompt-injection defense ever gets a vote. We meet the same seam in every harness we test, and it matches the loopback control plane in CVE-2026-82533: any local binary or API the agent may call without approval is attack surface. Our sandbox escape report catalogs the wider family.

The paths a poisoned repository takes to a developer machine

Cloning from a remote drops local config, so a fresh clone of a public repository arrives clean. The risk travels when folders move as files: zipped handoffs, CI artifacts, vendor drops, archived workspaces, and fork pull requests checked out with their .git directory intact.

Agents widen the door by inviting folders in. Every harness accepts a local path as a workspace, and almost nobody reads .git/config before opening one. We treat any repository that did not arrive as a fresh clone from a canonical remote as untrusted input, the same class as a stranger's script, and our untrusted code guide spells out the handling rules we apply.

The six-step check before any agent opens a folder

  1. List config origins with git config --local --list --show-origin, and read every value that names a program twice: as a feature, and as a threat model.
  2. Grep the output for the execution sinks, meaning fsmonitor, sshCommand, filter, textconv and askpass keys that point at binaries you did not put there yourself.
  3. Diff the folder's config against a clean clone of the same remote, because one changed line hides comfortably among two hundred honest ones.
  4. Re-clone anything that arrived as files. Cloning drops local config, which makes the fresh clone both the verification and the fix in a single move.
  5. Run git -c core.fsmonitor=false status while you confirm your harness build against the vendor changelog, so the sink stays disabled during the check itself.
  6. Put steps one through four into CI for every fork pull request, the one path where a stranger's .git directory reaches your runners by design.

Teams running agents in isolated cloud environments get a cheaper step four: the folder lands in a workspace that dies with the session, so a missed sink costs a disposable box, not a laptop.

The patch map: four fixed, four open

According to Manifold's disclosure of 1 September 2026, eight flaws spanned those seven agents with four unpatched at publication. Claude Code fixed the fsmonitor path in 2.1.196, Codex CLI shipped CVE-2026-19592 in 0.131.0 with CVE-2026-19593 covering the desktop app, and Goose carries CVE-2026-72718, fixed in 1.44.0. Cursor patched in its current release at the time. Version checks are therefore a security control, not hygiene, and the October roundup by Adversa tracks what moved since.

Hermes Agent (CVE-2026-71963), plus the Qwen and Grok harnesses, had no published fix at disclosure, as reported by Manifold's status table. Claude Code's ultrareview path kept a second config key live at version 2.1.252. Unsetting core.fsmonitor is necessary and not sufficient. Until your harness shows up in the fixed column, the folder is your boundary, which is exactly why we run stranger repositories inside their own microVM with no route back to the host.

Verdict, and the caveats on this page

Our verdict: patch your harness, then change how folders arrive. The patches close four of eight paths and more fixes will land, but the arrival path belongs to you alone, and it is the one segment attackers control end to end. Treat a handed-off repository the way you treat a handed-off binary.

  • This page covers the git config class only; plugin-update hijacks and subagent-config tricks from the same month do not belong here and need their own runbooks.
  • Patch status moves: the fixed column is a September snapshot plus vendor changelogs, and staleness is the built-in limitation of disclosure-driven pages.
  • We test on Linux microVMs, so Windows and macOS harness builds expose sinks we never exercised, and Seatbelt or Landlock backends change the blast radius.
  • Static scanning fails the last case: no signature catches a repository whose only malicious line is a config value your own team added last quarter.

FAQ

Does cloning a repository protect me from GitSpawn?

Cloning from a canonical remote drops local config, so the clone itself arrives clean. The protection ends the moment a folder travels as files instead: zips, CI artifacts and vendor drops carry .git/config with them. Clone again before any agent opens a handed-off directory, and keep the original quarantine.

Which agents were still vulnerable at publication?

Hermes Agent, Qwen Code and Grok Build had no published fix in Manifold's 1 September 2026 disclosure, and Claude Code's ultrareview path remained open at version 2.1.252. Check your exact build against the vendor changelog, because patch status decides whether the folder or the harness is your real boundary today.

Is GitSpawn a prompt injection attack?

No. The model never reads the payload, and no injected instruction is involved anywhere in the chain. Git executes the config value directly, as your user, before the agent reasons about anything. Approval prompts, scanning and sandboxing all miss it because the decision belongs to git.

Open folders like they are code

Krova Cubes run every untrusted repository in its own Firecracker microVM with no public IP and egress you allowlist, so a poisoned config executes inside a box with nothing worth stealing.

For AI agents:llms.txtsitemap

Related posts