GitSpawn: A Rogue .git Config Can Hijack Your AI Coding Agent

Introduction: The Attack That Fires Before You Type

On September 3, 2026, Manifold Security disclosed a vulnerability class it named GitSpawn, and the details should make every developer using an AI coding agent sit up straighter. Eight related flaws were documented across seven widely used agents — Claude Code, OpenAI Codex, Cursor, Block’s Goose, Alibaba’s Qwen Code, xAI’s Grok Build, and Hermes Agent. Four of them remained unpatched at publication.

The core finding is unsettling in its simplicity: a malicious repository can execute attacker-chosen code on your machine the moment your AI coding agent opens it. No prompt typed. No approval clicked. On several affected tools, the payload fires before the workspace-trust dialog appears — and on Qwen Code, before the user has even authenticated to the tool. The command runs with your full local privileges, outside the agent’s sandbox, and completely beneath the approval and logging layers vendors built specifically to gate agent-initiated execution.

The affected tools collectively represent close to half a million GitHub stars, with Claude Code alone accounting for more than 77 million npm downloads a month. This is not a niche CLI issue — it’s a structural crack in the way modern AI development workflows ingest untrusted code.

How GitSpawn Works: core.fsmonitor, Weaponized

The attack exploits a legitimate Git performance setting called core.fsmonitor. Normally, fsmonitor names a helper program that Git runs automatically whenever it refreshes a repository’s file index — a routine optimization that large repos use to avoid rescanning every file.

Here’s the problem: AI coding agents gather project context by quietly running background commands like git status and git diff the moment they open a project. Each of those commands refreshes Git’s index. If the repository’s .git/config contains a malicious fsmonitor entry pointing at an OS command of the attacker’s choosing, Git executes it — as a native Git subprocess, not as an agent tool call.

That distinction is everything. Every confirmation dialog, sandbox, and permission prompt an agent applies to model-generated shell commands exists inside the agent’s tool-execution layer. A Git-invoked helper process never touches that layer. From the agent’s perspective, it merely asked Git a question and Git answered — while underneath, the attacker’s command exfiltrated your environment variables, SSH keys, cloud credentials, and shell history, or downloaded a second-stage payload.

Manifold’s timing analysis makes the severity concrete: on Claude Code and Hermes Agent, the payload fires before the workspace-trust prompt is accepted; on Goose, before the tool ever contacts the model; on Grok Build, on the very first keystroke inside the project. The “review before you trust this folder” safeguard that vendors treat as their primary defense simply does not apply to this attack class.

How the Booby-Trapped Repo Reaches You

One important nuance limits the blast radius: a normal git clone from a remote does not reproduce this risk. Clone operations don’t copy the source repository’s local, non-shared configuration. The victim has to receive the repository as a directory tree with its .git/config still in place.

That sounds like a narrow condition until you think about how projects actually move between people in 2026:

• A .zip archive of a project shared in Slack, email, or a freelance marketplace
• A folder handed over on a shared network drive or synced through cloud storage like Dropbox or Drive
• A USB stick from a consultant or contractor
• A take-home assignment zip from a job candidate — a scenario where developers deliberately open untrusted code

These are exactly the channels colleagues and contractors routinely use to hand off projects. No social engineering beyond “here’s the codebase, take a look” is required.

The Scoreboard: Eight Flaws, Seven Agents, Four Unpatched

Manifold retested every affected agent on September 1, 2026, and the remediation picture is uneven. Goose shipped a fix and received CVE-2026-72718. Cursor and OpenAI Codex patched their affected paths after independent researchers filed overlapping findings. But four of the eight issues were still open at disclosure:

• Qwen Code — accepted by Alibaba, confirmed vulnerable at v0.19.6 and v0.22.3, unpatched
• Grok Build — closed as a duplicate without a fix, confirmed vulnerable at v0.2.93 and v1.0.13
• Hermes Agent — no formal triage despite multiple contact attempts; tracked as CVE-2026-71963
• Claude Code — a distinct second variant beyond core.fsmonitor, tied to the ultrareview feature and abusing a different Git configuration key, confirmed vulnerable at v2.1.252

The Cloud Security Alliance, which published two research notes on the disclosure, draws the right conclusion: the recurrence of trust-boundary failures across GitSpawn, the related GhostApproval symlink bypass, and Cursor’s unpatched git.exe zero-day suggests this is “a predictable category of vulnerability rather than a series of coincidental implementation bugs.” The design pressure to make repo ingestion fast and frictionless keeps producing the same crack.

Why AI Agents Made This Possible

Git’s fsmonitor setting has existed for years — but before agents, it mattered less, because human developers don’t reflexively run git status on every folder they receive within milliseconds of opening it. AI coding agents do exactly that, automatically, as their first act of context gathering. The vulnerability sits at the intersection of an old Git footgun and a new class of software that touches untrusted repositories with your full privileges at machine speed.

For teams evaluating coding agents, this changes the procurement conversation. The CSA recommends requiring vendors to state their GitSpawn remediation status explicitly rather than assuming that no public advisory means no exposure — several vendors here closed reports as duplicates or went silent, which wouldn’t surface in a casual security review.

If you’re choosing an agent for your team, it’s worth comparing how seriously each vendor treats background execution: see our pages on Claude Code, Cursor, OpenAI Codex, GitHub Copilot, Windsurf, and Aider for each tool’s sandboxing and permission model.

How to Protect Yourself and Your Team

The good news: mitigations are cheap and don’t require waiting for vendor patches.

• Treat folder handoffs as untrusted input. A zip, drive, or synced folder containing a .git directory is categorically riskier than a clone from a known remote — it’s precisely that preserved local config that enables the attack.
• Inspect before opening. Check .git/config for unexpected [core] entries — especially fsmonitor — before pointing any agent at a received project.
• Re-clone when possible. If the project has an upstream remote, clone it fresh instead of using the handed-off directory.
• Ask your vendor. Require an explicit statement of GitSpawn remediation status in procurement and renewal conversations, as the CSA advises.
• Isolate agent environments. Run agents in sandboxes or VMs that constrain what any Git-invoked helper process can reach, rather than trusting the agent’s own approval layer — this attack class bypasses it entirely.

For vendors, Manifold’s fix recommendation is direct: sanitize Git configuration state on every background invocation — for example, invoking git -c core.fsmonitor=false status rather than trusting the repository’s ambient settings. Any execution that happens during automatic context gathering, before a model call or trust dialog, must be treated as security-critical in its own right.

Frequently Asked Questions