September 2026 · 6 min read
GitSpawn: untrusted repos run code in coding agents
Key Definitions
GitSpawn A vulnerability class named by Manifold Security: AI coding agents gather context with git in the background without stripping the repository's own git config, so a malicious setting (e.g. core.fsmonitor) makes a repo delivered as files run arbitrary code on the host with the developer's privileges.
core.fsmonitor A git performance setting: for large repos, instead of checking every file on disk, git asks a helper program what changed and runs it during an index refresh. Git reads this setting from the repository's own .git/config — the repo gets to name the command that runs.
Context gathering The background flow a CLI AI agent runs at startup — using git to learn the current branch, changed files, and what a change touched — before the user types a prompt (and on some agents before authentication). It is the entry point for this vulnerability.
On September 1, Manifold Security published GitSpawn: open a folder with Claude Code and it runs git status before you type anything — and if that folder came from somewhere else, the repository decides what that command runs. Multiple mainstream coding agents (Claude Code, Goose, Grok Build, Qwen Code, Hermes; Codex and Cursor in the same class) gather context with git in the background without stripping the repository's own git config, so a malicious repo can run arbitrary code on the host with the developer's privileges — before the workspace-trust prompt, outside the sandbox.
The mechanism: the git you didn't run
CLI AI agents all do the same thing at startup: gather project context in the background. They do it with git — the current branch, which files changed, what a change touched. The problem: those context-gathering calls run without stripping the repository's own git config, and several git settings are command-execution sinks.
core.fsmonitoris a performance setting for large repositories: instead of checking every file on disk, git asks a helper program what changed, and runs it during an index refresh. Git reads that setting from the repository's own .git/config, so a repository can ship this:
[core]
fsmonitor = <command>
Then any git command that refreshes the index — git status, git diff, whichever the agent chose — runs that command. The chain: agent startup → background git status/diff → index refresh → the command named in the repo's .git/config → executed on the host with your privileges. Because it is a subprocess spawned by the agent's own code, it runs outside the sandbox, without an approval prompt — the permission model never sees it.
Delivery: not a clone, but "arrives as files"
Delivery is worth being precise about, because git never carries this: cloning a hostile URL does nothing, and neither does fetch or pull. The repository has to arrive as files with its .git directory already inside — a shared zip, a shared drive, a sync folder, a USB stick. That is how colleagues pass projects around and how consultants hand them to clients. Every proof of concept in Manifold's research used a zip.
Scope: 7 agents, 8 findings, 4 unpatched
Goose — Patched
Triggered while goose review built a diff. Affected 1.41.0, fixed in 1.44.0. CVE-2026-72718, scored 7.0 by the maintainers, assigned after our report.
Claude Code (core.fsmonitor) — Patched
Ran git status at startup as an internal subprocess outside its sandbox. Confirmed on 2.1.193, fixed by 2.1.196. Our report was closed as a duplicate of a same-day report.
Claude Code (ultrareview) — Unpatched
A different git setting of the same kind, which the review path does not strip. The malicious command runs on startup, before the workspace-trust prompt is shown or accepted. Confirmed still unpatched on 2.1.252.
Qwen Code — Unpatched
Runs git status at startup to gather context. Reported on 0.19.6 to Alibaba's security response center and accepted; confirmed still unpatched on 0.22.3. The trigger fires before the user has even authenticated.
Grok Build — Unpatched
Runs git to gather context. An earlier report of the same class, filed July 1, was closed as informative; ours followed on July 14 and was closed as a duplicate. Confirmed still unpatched on 1.0.13.
Hermes Agent — Unpatched
Runs git status in the session directory to gather repository context without stripping the repo's config. After reporting on 0.18.2, six contact attempts across five channels produced no triage; confirmed still unpatched on 0.21.0. CVE-2026-71963 was assigned by VulnCheck, an independent CNA, not the vendor.
Codex and Cursor — Patched
Same class with somewhat different mechanisms; both were reported, closed as duplicates of other researchers' reports, and have since been patched.
Why this is systemic
This is not one vendor's isolated bug. Every agent examined uses the same flow — gathering context with git without sanitizing repository config. Five of Manifold's eight reports came back as duplicates of findings other researchers had already filed independently, one on the same day. Being found from multiple directions is the signature of a systemic defect in the coding-agent plumbing, not a research accident.
The footprint makes it worse: Claude Code alone ships over 77 million npm downloads a month, and the named projects total close to half a million GitHub stars. Coding agents have moved from optional tooling to the default development entry point — one that can execute arbitrary code with the user none the wiser.
What this means for enterprises and developers
Coding agents are a new supply-chain endpoint
Opening a zip or a shared directory for a coding agent is granting that code execution on your machine. Developer machines hold SSH keys, cloud credentials, and every repository — precisely what attackers want.
Upgrading is not the same as being fixed
Four findings were still live at publication, and other git settings of the same kind exist beyond core.fsmonitor. Verify your exact version against the affected list — do not assume "latest" means safe.
Treat coding agents as a sandboxing problem
On developer machines that run coding agents, apply OS-level isolation and network egress control to the agent process; for repos from outside (zip, shared drive, client delivery), inspect .git/config before opening.
Three steps to act
Check whether your coding agent version is patched
Compare against the affected list: Claude Code ≥2.1.196 (core.fsmonitor fixed, but the ultrareview path is not), Goose ≥1.44.0; Qwen Code, Grok Build, and Hermes are unpatched — add extra controls for those.
Treat external repos as untrusted code
Before opening a zip, shared drive, or client-delivered project, check .git/config for suspicious settings (core.fsmonitor, core.pager, aliases — command-execution sinks). Make it a team-wide check.
Add OS-level isolation for coding agents
Run coding agents in controlled environments or sandboxes, restrict network egress, and isolate developer credentials. Where the agent supports it, disable background auto git context-gathering or force a sanitized invocation (e.g. git -c core.fsmonitor=false).
References
- Manifold Security: GitSpawn — A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok (2026-09-01) — https://www.manifold.security/blog/ai-coding-agents-git-hijack
- Goose advisory: GHSA-r5pp-p5r8-466r / CVE-2026-72718 — https://github.com/aaif-goose/goose/security/advisories/GHSA-r5pp-p5r8-466r
- Hermes Agent CVE-2026-71963 — https://www.cve.org/CVERecord?id=CVE-2026-71963
FAQ
What is GitSpawn?+
A class of coding-agent vulnerabilities disclosed by Manifold Security on Sept 1: agents gather context with git in the background without stripping the repository's own git config, so a malicious core.fsmonitor (or similar) setting runs an arbitrary command on the host with developer privileges during an index refresh — before the workspace-trust prompt, outside the sandbox.
What does an attacker get?+
Arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen: their SSH keys, cloud credentials in the environment, tokens in shell config, every repository on disk, and a foothold on the machine.
How does a malicious repo spread?+
Not by cloning — cloning a hostile URL, fetch, and pull all do nothing. The repo must arrive as files with its .git directory already inside: a shared zip, a shared drive, a sync folder, or a USB stick. That is how colleagues pass projects around and how consultants hand them to clients.
Which agents are affected?+
Manifold disclosed 8 findings across 7 agents (Claude Code ×2, Goose, Grok Build, Qwen Code, Hermes; Codex and Cursor are the same class but already patched). At publication, 4 were unpatched: Qwen Code, Grok Build, Claude Code's ultrareview path, and Hermes (CVE-2026-71963). Goose is fixed (CVE-2026-72718) and Claude Code's core.fsmonitor variant is fixed.
Why is this a systemic problem?+
Because it is not one vendor's bug: every agent examined uses the same flow — gathering context with git without sanitizing repository config. Five of Manifold's eight reports came back as duplicates of findings other researchers had already filed independently. Being found from multiple directions is the signature of a systemic defect in the coding-agent plumbing.
Related Articles
Trojanized AI Skills: a 1.7M-Install Supply Chain Attack
Trojanized AI agent skills on skills.sh amassed 1.7M+ installs since July 11, installing a credential stealer.
GhostSplice: MCP Servers Split Instructions to Steal Keys
ASSET Aug 11: malicious MCP servers split an exfiltration instruction across tool calls so no single call looks harmful.
Three AI Coding Tool Incidents in One Week
Three independent AI coding tool safety incidents within a single week: ransomware, deleted databases, silent uploads.
Ransomware Used Cursor's Agent: Refusal Isn't Authorization
Aurora ransomware used Cursor's agent for hundreds of ops by claiming a 'test'. Refusals live in model logic.