A Malicious Git Config Can Hijack Your AI Coding Agent
TechCurrent Staff•Sep 3•5 min read

Update, September 13, 2026: Hermes Agent shipped a fix on September 7 (0.21.1; current release 0.21.2), so the advice to avoid it no longer applies. The CVE tracking that flaw, CVE-2026-71963, has since been published at CVSS 8.6 High. Every version number and status below has been re-verified today, and the original September 3 table is superseded.
Your AI coding agent runs git commands you never see. Open a folder and it quietly calls `git status` or `git diff` to understand the project before you type a word. On September 1, Manifold Security disclosed a class of vulnerabilities it calls GitSpawn that turns that habit against you: a repository's own `.git/config` file can set git's `core.fsmonitor` option to an arbitrary command, and git will execute that command whenever it refreshes its index. The result, in Manifold's words: "Arbitrary code execution as the developer, outside the sandbox, with no approval prompt and nothing on screen."
Manifold documented eight findings across seven agents: Claude Code, OpenAI's Codex, Cursor, goose, Qwen Code, Grok Build and Hermes Agent. The Hacker News corroborated the research on September 2. As of September 3, four of the eight findings show no evidence of a fix. No exploitation in the wild has been documented so far, though absence of reports is not proof of absence.
Anyone who followed August's npm worm, which hid in agent hook systems, will recognize the shape of this. In both cases, agents auto-execute configuration that developers never review, and they do it before their own trust prompts fire.
Git runs whatever `core.fsmonitor` names
`core.fsmonitor` is a legitimate git performance feature. Per the official git documentation, the setting can hold "the pathname of the 'fsmonitor' hook command", a helper git invokes to learn which files changed, so that commands like `git status` run faster on huge repositories. Git executes whatever that setting names, and the setting can live in the repository's own local config.
Git itself is behaving exactly as documented here, and Manifold is explicit that this "exploits a legitimate feature, not a bug." The agent-side mistake, as OpenAI's CVE-2026-19592 record puts it for Codex, is collecting git metadata "without disabling the repository-local core.fsmonitor setting", so the helper runs outside the sandbox, without an approval prompt, with the user's privileges.
According to Manifold, Claude Code ran its first `git status` before the workspace-trust prompt appeared. Qwen Code executed the payload on start-up before the user had even authenticated. Grok Build fired on the first keystroke, before any message was sent. goose's case, per its GitHub advisory, involved "no submitted prompt, no model call, no tool approval, no trust prompt." Trust dialogs exist in most of these tools; the context-gathering git calls simply ran first.
A fresh clone can't carry the payload
A fresh `git clone` is safe. Cloning does not carry over the source repository's local config, a point both Manifold and the Codex CVE record make explicitly. In Manifold's words: "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, so the vector is anything that moves a directory instead of cloning it: a shared `.zip`, a shared drive, a sync folder, a USB stick."
In practice, the dangerous object is the zipped "take a look at this project" folder, the repo on a team shared drive, the synced directory, the take-home assignment. If it arrived with a `.git` folder inside and you did not clone it yourself, its config is untrusted executable input.
Where the eight findings stand
Status re-verified September 13, 2026. This table ages quickly, so check your vendor's latest release before relying on it.
| Agent | Status | Detail |
|---|---|---|
| OpenAI Codex CLI | Patched | Fixed in 0.131.0 (affected 0.102.0 to 0.130.0), per CVE-2026-19592; Codex Desktop fixed in macOS 26.519.22136 and Windows 26.519.21041 |
| goose | Patched | Fixed in 1.44.0, per CVE-2026-72718 (CVSS 7.0 High); trigger was the `goose review` command |
| Claude Code (main path) | Patched, per Manifold's re-testing | Fixed in 2.1.196, three days after Manifold's report; Anthropic has published no advisory and the release notes do not mention it |
| Cursor | Patched, per Manifold | No version number or advisory has been published |
| Claude Code (/ultrareview path) | No evidence of a fix | A different git config key, which Manifold is deliberately not naming while unpatched. Confirmed vulnerable in 2.1.252, and nothing in the changelog through 2.1.270 indicates a fix. An absent changelog entry is not proof no fix shipped |
| Hermes Agent | Patched | Fixed in 0.21.1, released September 7; current version is 0.21.2. Tracked as CVE-2026-71963 (CVSS 8.6 High), affecting 0.18.2 through 0.21.0 |
| Qwen Code | Fix written, not yet shipped | A fix was merged to the main branch on September 12, but it is not in the current release (0.23.3) or the nightly build, so anyone on a published version is still running unfixed code |
| Grok Build | Unclear | xAI has published no advisory. Its public source (now 1.0.24) does strip the fsmonitor setting on the session-startup `git status`, and that code first appears in the August 31 source sync. We cannot reconcile that with Manifold confirming 1.0.13 vulnerable, so we are not calling it fixed |
The disclosure log behind that table shows how differently vendors handled the same report. OpenAI had already fixed it before Manifold's report arrived (its fix merged in May; Manifold's July report came back as a duplicate). Anthropic fixed the main path in three days but the second finding, reported July 15, remained open at publication. And Hermes Agent, per Manifold, never triaged the private advisory after "six contact attempts across five channels"; the CVE for it (CVE-2026-71963) was assigned by VulnCheck, a third-party numbering authority rather than the vendor. It was published on September 3 at CVSS 8.6 High, and the vendor shipped its fix on September 2, the day after the disclosure.
Git's fsmonitor has also surfaced in an Anthropic advisory before. The company's June advisory for a different flaw (CVE-2026-55607, a sandbox escape via git worktree path confusion, fixed in 2.1.163) already had git's fsmonitor execution in its mechanism chain. GitSpawn is not that bug, but the ingredient list overlaps.
Repo-local config beats your global settings
Some coverage suggests disabling the feature globally with `git config --global core.fsmonitor false`. That advice fails, because git's repository-local config overrides global config: the attacker's setting in the copied repo wins. TechCurrent verified this locally against git 2.51.0, and it matches git's documented scope precedence. The fix that actually holds is the one Manifold gives vendors: strip the setting per invocation, as in `git -c core.fsmonitor=false status`, because a command-line `-c` overrides every config file.
What to check before opening a copied repo
- Clone, don't copy. If a project reaches you as a ZIP, shared-drive folder, sync folder or USB copy with `.git` inside, treat it as untrusted. - Before opening a copied repo with any agent, inspect from a plain shell: `git config --get core.fsmonitor`, and read `.git/config` generally. Per Manifold, "Any setting that names a program can run it"; The Hacker News also points at `core.hooksPath` and filter settings. - Deleting the `.git` directory from a copied project before opening it removes the repo-local config entirely (TechCurrent guidance, following from the mechanism as publicly described). - Update now: Codex CLI 0.131.0 or later, goose 1.44.0 or later, Claude Code 2.1.196 or later, current Cursor. - Until fixes ship: update Hermes Agent to 0.21.1 or later, treat Qwen Code and Grok Build as unresolved when opening repos you did not clone yourself, and avoid running `/ultrareview` in copied repos (status as of September 13).
None of the four vendors with open findings had publicly responded to the September 1 disclosure as of September 3. We will update our coverage when they do, and when the remaining fixes land.
“Cloning a hostile URL does nothing. The repository has to arrive as files with its .git directory already inside.”
Reporting by TechCurrent Staff · TechCurrent
