GitSpawn - Malicious .git Configs Make Coding Agents Run Attacker Code
On 1 September 2026, Manifold disclosed GitSpawn: malicious .git/config entries - especially core.fsmonitor - that cause coding agents to execute attacker-controlled commands when they run routine git status or git diff during context gathering. The Hacker News and a Cloud Security Alliance research note covered the same findings in the days that followed. This advisory summarizes the verified facts, the patch matrix Manifold reported, and how to inventory and govern the agent/Git hinge across a fleet.
What happened
Coding agents gather repository context by shelling out to Git. When a project ships a poisoned .git/config, Git honors helpers such as core.fsmonitor on status and diff. That helper is a command path chosen by whoever wrote the config. Manifold showed the resulting process runs outside the agent sandbox and typically without an approval prompt, because the agent asked Git for status - not for permission to run an arbitrary binary.
Delivery is deliberately mundane. The attacker does not need the victim to git clone a hostile remote. A zip file or shared folder that already contains a .git/ directory with the malicious config is enough: the developer opens the folder in the agent, the agent runs status/diff, and GitSpawn fires. That is a different shape from clone-time trust assumptions many teams still use when they review "where did this repo come from."
The pattern sits next to other Git-config trust failures on coding endpoints - including the Cursor Git-hooks sandbox escape and Cursor DuneSlide sandbox escapes - and next to project-file execution before consent such as Claude Code project-file RCE and token exfiltration. The shared lesson: repository-local configuration is an execution path, not documentation.
Patch and exposure matrix (as of Manifold's Sep 1 retest)
- goose 1.44.0 - fixed; tracked as CVE-2026-72718 (CVSS 7.0).
- Codex CLI 0.131.0 - fixed; tracked as CVE-2026-19592.
- Cursor - vendor patch reported for the GitSpawn / fsmonitor class.
- Claude Code -
core.fsmonitorpath fixed by 2.1.196; Manifold still flagged an ultrareview path as open at retest. - Hermes - still unpatched at retest; tracked as CVE-2026-71963.
- Qwen Code and Grok Build - still unpatched at Manifold's 1 September retest.
Treat that matrix as a point-in-time snapshot from the disclosure. Before closing a ticket, confirm the current release notes for each agent your developers actually run - especially Codex desktop versus CLI strings, Claude Code ultrareview status, and whether Hermes CVE-2026-71963 has a fixed build in your channels.
Why this is an agentic-endpoint risk
The dangerous surface is the coding agent plus Git, not a remote service. Status and diff are everyday agent behaviors described in guides such as the OpenAI Codex sandbox and approval model and the broader securing AI coding agents and CLIs pillar. When those ops honor attacker-controlled .git/config, the sandbox and approval story your team thinks it bought does not cover the spawn.
Network and EDR still see a legitimate git parent launching a helper. DLP does not see a "malicious tool call" because the agent never framed one. The exposure lives in the AI artifact layer: which agents and CLIs are installed, which versions, and whether they auto-run Git against trees that arrived as archives. That is one of the eight AI artifact types Anomity tracks per endpoint - the same shadow-IT dynamic as AI agents becoming the new shadow IT.
How Anomity surfaces and governs it
Patching each agent closes the specific GitSpawn paths vendors have fixed. The durable control is still to see which agents run where and to decide tool and subprocess behavior before it runs. Anomity does that in three steps.
First, inventory. The Endpoint Sensor inventories agents and CLIs (among the eight AI artifact types) on every managed endpoint, so you can find builds that still match Manifold's unpatched set - Hermes, Qwen Code, Grok Build, and older goose / Codex / Claude Code / Cursor versions - without waiting for a developer survey. Metadata only; secrets are redacted on the endpoint.
Second, decide at the hook. On agents that expose a hook such as Claude Code PreToolUse, runtime governance returns allow, deny, or log before the call runs. That does not replace vendor GitSpawn patches, but it gives you a policy boundary for high-risk tool and shell behavior while vulnerable builds are still rolling off the fleet.
Third, keep the record. Every decision lands in a queryable 90-day audit trail and can route to SIEM, Slack, email, or Jira. When the next Git-config disclosure lands, you answer from a record which endpoints ran which agents - not from a guess. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC; it covers the artifact layer those tools were not built to inventory. See how it works or book a 30-minute demo.
What to check across your fleet
- Inventory every endpoint running goose, Codex CLI, Cursor, Claude Code, Hermes, Qwen Code, or Grok Build, and compare versions to Manifold's Sep 1 matrix (goose 1.44.0+, Codex CLI 0.131.0+, Claude Code 2.1.196+ for the fsmonitor path, Cursor patched builds).
- Treat zip / shared-folder project intake as untrusted input equal to cloning an unknown remote - inspect
.git/configforfsmonitor, hooks, and other helper keys before an agent opens the tree. - Disable or ignore repository-local Git helpers in enterprise Git policy where feasible, and alert on unexpected
.git/configwrites. - Re-verify Claude Code ultrareview and Hermes CVE-2026-71963 status on current releases before closing the ticket.
- Confirm coding-agent tool calls are evaluated with allow/deny/log at the agent hook, and that decisions land in a 90-day audit trail.
GitSpawn is another reminder that agent context gathering is an execution surface. Patch the agents Manifold named, assume archive delivery is in scope, and inventory the coding-agent fleet so the next .git/config helper does not land on an invisible population. For sandbox and approval baselines, see the Codex sandbox and approvals guide. To inventory and govern coding agents across your endpoints, book a 30-minute demo.
Frequently asked questions
What is GitSpawn?
GitSpawn is the name Manifold gave to a class of coding-agent remote code execution disclosed on 1 September 2026. An attacker plants a malicious Git configuration - commonly core.fsmonitor - inside a project's .git/config. When a coding agent later runs git status or git diff to gather repository context, Git launches the configured helper, and the attacker's command runs on the developer workstation. The chain does not need the agent to approve a shell tool call; Git is doing the spawn.
Why does core.fsmonitor matter for coding agents?
core.fsmonitor tells Git which program to run when it wants filesystem-change hints. Agents routinely invoke git status and git diff while building context for a task. If that config points at attacker code, those everyday Git operations become the execution trigger. Because the spawn comes from Git rather than from an agent tool policy, it often runs outside the sandbox and without the approval UI developers expect for dangerous commands.
Which agents were patched, and which were still open?
Per Manifold's disclosure and follow-on coverage: goose fixed the issue in 1.44.0 under CVE-2026-72718 (CVSS 7.0); Codex CLI fixed it in 0.131.0 under CVE-2026-19592; Cursor shipped a vendor patch; Claude Code fixed the core.fsmonitor path by 2.1.196. At Manifold's 1 September retest, Hermes remained tracked as CVE-2026-71963, and Qwen Code, Grok Build, and a Claude Code ultrareview path were still unpatched. Teams should re-verify current release notes for each agent before treating a build as closed.
How is this different from the Cursor Git-hooks sandbox escape?
The Cursor Git-hooks issue (CVE-2026-26268) centered on an agent writing Git hooks from inside a sandbox so a later Git operation ran outside it. GitSpawn centers on a pre-planted .git/config helper that fires when the agent merely reads repository state. Both abuse Git's trust in repository-local configuration; the delivery and trigger differ. Defenders should treat any agent that auto-runs Git against untrusted trees as in scope for both patterns.
How does Anomity reduce exposure to this class of flaw?
Anomity inventories AI agents and CLIs on every managed endpoint, so you can find which endpoints still run unpatched coding-agent builds. On agents that expose a hook such as Claude Code PreToolUse, Anomity returns allow, deny, or log before a tool call runs, and records decisions in a queryable 90-day audit trail routed to SIEM, Slack, email, or Jira. Metadata only leaves the endpoint; secrets are redacted on-device. That complements Network, EDR, DLP, and GRC controls that were not built to inventory the agent artifact layer.
