GitSpawn: How a .git Config Hijacks 7 AI Coding Agents

A malicious .git config can make AI coding agents run attacker code with zero approval. Seven vendors were affected, and most still are.

GitSpawn is a disclosed flaw where a malicious .git config setting makes AI coding agents execute attacker-controlled code with zero approval, before the user types a single instruction. It does not target one AI coding tool. It targets a habit nearly all of them share: Claude Code, Codex, Cursor, Goose, Grok Build, Hermes Agent, and Qwen Code were all found capable of executing that code from nothing more than a repository sitting on disk.

Sources: The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

Manifold Security, the firm behind the disclosure, reported eight distinct flaws across these tools in total, GitSpawn being the one that repeats across the largest number of vendors. None of it requires phishing, a stolen credential, or a malicious prompt typed by a careless developer. It requires only that the developer open a folder.

Sources: The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

The mechanism: a git setting agents never think to distrust

Every one of these agents runs background git commands, things like git status and git diff, to figure out the current branch and what has changed. That is normal and useful behavior; agents need repo context to be helpful. The problem is what git itself does when it runs those commands. Git supports a config directive called core.fsmonitor, a performance setting that names an external program git should ask about which files changed, instead of scanning the whole working tree itself. If a repository ships a .git/config file that points core.fsmonitor at an attacker-chosen command, then the next time anything runs git status or git diff inside that repository, git executes that command. Not the agent. Git.

Sources: Manifold Security: AI Coding Agents Git Hijack

core.fsmonitor exists for a good reason. On a large monorepo, walking the entire working tree to see what changed is slow, so git lets a long-running watcher process answer that question instantly instead. It is the kind of setting a repository maintainer sets once and forgets about, which is exactly why nobody built a review step around it. An agent has no reason to open .git/config and ask whether the fsmonitor line looks suspicious, because until now, nothing about that file was treated as content an attacker might control.

That distinction is what makes GitSpawn dangerous. The agent never decided to run untrusted code. It ran a routine context-gathering command, and git quietly handed execution to whatever the repository told it to run, with the developer's own privileges, outside any sandbox the agent maintains, and without an approval prompt, because from the agent's perspective it only asked git a question.

The exploit does not survive a normal clone. When a repository is fetched over the network with git clone, the source machine's local .git/config is not what gets written to disk on the receiving end. GitSpawn instead requires the .git directory to arrive intact as files: a zipped project shared over email or Slack, a folder copied off a shared drive, a repo dropped onto a USB stick, or restored from a backup. Anyone who has ever received a project as a zip file rather than cloning it has handled exactly the kind of package this attack rides in on.

Sources: Manifold Security: AI Coding Agents Git Hijack

• Claude Code ran the vulnerable git status call before its own workspace-trust prompt was even accepted.
• Qwen Code triggered on startup, ahead of user authentication.
• Grok Build fired on the first keystroke in a session.
• Hermes Agent executed as soon as the user sent a first message.
• Goose triggered specifically during its goose review command.

Who patched, who did not

Manifold Security reported the issues to each vendor between late June and late July 2026 and published its findings on September 1 and 2, the same window in which OpenAI issued its own related CVEs. Sonar had already flagged closely related git-config trust issues back in April, so this was not the first warning the ecosystem received. By the time of publication, patch status was split roughly down the middle.

Sources: The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

The scale behind those version numbers is not small. Claude Code alone sees roughly 77 million npm downloads a month, and the combined GitHub star count across the affected projects closes in on half a million. Manifold also found no evidence of active exploitation, and CISA's Known Exploited Vulnerabilities catalog, which held 1,687 entries as of September 2, listed none of these CVEs. GitSpawn is a disclosed design flaw, not yet an observed campaign, though that gap has a way of closing quickly once a working technique is public.

Sources: Manifold Security: AI Coding Agents Git Hijack, The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

The vulnerable agents were not the first developer tools to fall for a trust-bypass problem shaped like this one. Versions of Visual Studio Code before 1.63.1 and JetBrains IDEs before 2021.3.1 both shipped comparable workspace-trust bypasses years earlier. The pattern keeps recurring because every new generation of developer tooling re-learns the same lesson: a workspace on disk is not neutral data, it is a program waiting for something to interpret it.

Sources: The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

This is not a theoretical risk for every agent on this list either. Hermes Agent, one of the tools still unpatched at publication, had already been used unattended in a July intrusion against a Thai government network, according to Manifold's report. An unpatched, silently-exploitable code execution path in a tool with that kind of deployment history is a different order of risk than a theoretical proof of concept.

Sources: The Hacker News: Malicious Git Configs Can Make Claude Code, Codex, Cursor Run Attacker Code

Why this is a pattern, not a single vendor's bug

Seven independent products, built by seven separate teams on different codebases, converged on the same blind spot. That convergence is the actual story. Every coding agent needs to answer the same question the moment it opens a folder: what is going on in this repository. The fastest way to answer it is to ask git, because git already knows the branch, the diff, and the file state. What none of the seven agents did was treat the repository's own configuration as part of the untrusted input it was reading context from. A file changed under version control gets scrutiny. A setting sitting quietly in .git/config, read automatically by a tool the agent trusts completely, gets none.

That is a supply-chain problem dressed up as a git quirk. Anywhere an agent silently shells out to a helper program to gather context, whether that is git, a linter, a package manager, or a build tool, the helper program's own configuration becomes an attack surface the agent inherited without evaluating it. GitSpawn happened to be found in git first. There is no reason to assume it is the only tool in an agent's startup sequence with a config directive nobody audited for this purpose.

It also explains why patching is uneven rather than uniform. A fix here is not one line of code, it is a change in what an agent is willing to assume about the environment it starts in. Vendors who treat the repository as a first-class attacker in their threat model, the way Cursor and Codex evidently did, ship a fix quickly. Vendors who still model the repository as passive data to read, patch slowly, or not at all, because the fix requires rethinking a design assumption baked in from the start, not swatting a single bug.

What engineering teams can do now

• Upgrade Claude Code, Codex, Cursor, and Goose to the patched versions listed in each vendor's advisory, and treat Grok Build, Hermes Agent, and Qwen Code as exposed until their vendors confirm a fix.
• Never open an unfamiliar repository that arrived as a zip, shared-drive folder, or USB copy inside an agent-enabled editor. Re-clone it fresh over the network first so any embedded .git/config is discarded.
• Audit .git/config for core.fsmonitor and any other hook-like directive before trusting a repository obtained outside a normal clone.
• Run coding agents under an OS-level sandbox or a disposable container for any repository of unknown origin, so a subprocess spawned by git cannot reach SSH keys, cloud credentials, or sibling repositories on the host.
• Do not assume a vendor's silence means the report was a false positive. Qwen Code, Grok Build, and Hermes Agent were all confirmed vulnerable weeks before publication with no fix shipped.

Where independent review fits

GitSpawn sits upstream of anything TLM Forge inspects. It happens during context gathering, before a single line of agent-authored code exists to review, so no merge gate catches the exploit itself. But the underlying lesson generalizes past this one flaw: an agent operating on unreviewed inputs, whether that is a repository's hidden config or its own generated diff, cannot be the only judge of whether that input is safe to act on. TLM Forge applies that same principle to the code an agent produces once it starts working: a spec and plan signed off before implementation, adversarial reviewers in fresh context whose job is to attack the diff rather than approve it, and a scored merge gate that blocks the change until every critical finding is resolved. It will not stop a malicious core.fsmonitor entry. It exists so that the code an agent writes after opening that repository does not get to ship on the agent's own say-so either.