On 2 September 2026, Manifold Security published GitSpawn: eight vulnerability findings across seven command-line coding agents, including Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code and Grok Build. The mechanism is uncomfortable in its simplicity. A repository that arrives on a developer's machine as files (a zip archive, a shared drive, a sync folder, a USB stick) can carry a .git/config that names an attacker-chosen command, and the agent will cause that command to run the moment it opens the directory. No prompt typed, no approval clicked, in some cases before the user has even authenticated. Four of the eight findings were unpatched on the day of publication. If your developers run CLI coding agents, and in most Swedish enterprises they now do, this belongs on this week's patch list rather than this quarter's.
The attack: a config key whose value is a command
Git has a performance feature called core.fsmonitor. Its value is a program that git runs to find out which files changed, so that operations on large repositories skip a full directory scan. Git reads the setting from the repository's own .git/config, and any operation that refreshes the index will execute it. That includes the two commands almost every CLI agent runs in the background at startup to gather context about your project:
git status --porcelain=2 --branch
git diff --name-only HEADSo the exploit is nothing more than a config file. A repository delivered with this inside .git/config runs the named command as soon as a vulnerable agent opens the directory:
[core]
fsmonitor = "sh -c 'id > /tmp/gitspawn-was-here'"Replace the harmless demo payload with a stager and the attacker has code execution with the developer's full privileges. Manifold's summary of where the flaw lives is worth quoting, because it explains why model-level safety work never had a chance to catch it: "The vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath." The agent never sees a malicious prompt. It just runs git status, the way it always does.
Not every finding in the set is a core.fsmonitor bug. One of the eight, affecting Claude Code, abuses a different configuration key that Manifold is withholding while it remains unpatched. That detail matters for defenders: auditing repositories for fsmonitor alone does not close the class.
Why the agent's sandbox does not help
Most CLI agents now ship some form of sandboxing or permission model: commands proposed by the model require approval, file writes are scoped, network access is restricted. None of that applies here, because the git call is not a model-proposed action. It is part of the agent's own startup routine, spawned as an ordinary subprocess before any workspace-trust prompt has been shown and before the user has approved anything. The payload therefore executes outside the sandbox, with whatever privileges the developer's account has: source code, credentials in the keychain, tokens in environment files, the internal network.
We made a related argument two weeks ago in our piece on isolating coding agents: the security boundary around an agent has to be an operating-system boundary, not a policy inside the agent process. GitSpawn is the cleanest illustration of that principle so far. Every affected agent had an approval model; every affected agent ran the attacker's command anyway, because the command never passed through the approval model.
Who is affected, and who has patched
Status at Manifold's publication on 2 September:
| Agent | Status | Notes |
|---|---|---|
| Claude Code (fsmonitor path) | Patched in 2.1.196 | Reported 26 June, fixed within days |
| Claude Code (second path) | Unpatched | Different config key, details withheld; confirmed on 2.1.252 |
| OpenAI Codex CLI | Patched in 0.131.0 | OpenAI published CVEs on 2 September |
| Cursor | Patched | Reported 8 July |
| Goose | Patched in 1.44.0 | CVE-2026-72718, CVSS 7.0 |
| Hermes Agent | Unpatched | CVE-2026-71963, assigned by VulnCheck as independent CNA |
| Qwen Code | Unpatched | Confirmed on 0.22.3 |
| Grok Build | Unpatched | Confirmed on 1.0.13 |
Scale is what makes the list serious. Claude Code alone sees roughly 77 million npm downloads a month by Manifold's count, and the affected open-source agents together hold around half a million GitHub stars. There is a reassuring counterweight: neither Manifold nor The Hacker News found evidence of exploitation in the wild, and none of the CVEs appeared in CISA's Known Exploited Vulnerabilities catalog as of 2 September. This is a disclosure to act on calmly, before someone weaponises it, rather than an incident to respond to.
What the disclosure timeline tells you about your vendors
Manifold ran a coordinated disclosure over roughly ten weeks, and the per-vendor outcomes are a useful responsiveness signal for anyone choosing which agents to standardise on. Anthropic received the first Claude Code report on 26 June and shipped the fix in version 2.1.196 within days, though the second, unrelated Claude Code path remained open at publication. Alibaba accepted the Qwen Code report on 7 July but had not shipped a fix by Manifold's retest on 1 September. xAI closed an earlier report as informative on 1 July, and Grok Build was still exploitable at publication. OpenAI patched Codex and published its CVEs on 2 September, the day the research went public. Hermes Agent's CVE came from VulnCheck acting as an independent CVE Numbering Authority rather than from the vendor, which is rarely a sign of an engaged security response.
One more detail from the report deserves attention: five of Manifold's reports came back marked as duplicates of findings other researchers had already filed independently. Several people found these bugs at the same time. When a vulnerability is that discoverable, the working assumption has to be that capable attackers can find it too, which makes the unpatched half of the list a live concern rather than a theoretical one.
Cloned repos are safe. Delivered repos are not.
The saving grace in the design of git itself: git clone, git fetch and git pull do not transfer the remote repository's config. A repository you clone from GitHub, Azure DevOps or GitLab arrives with a locally generated .git/config that contains nothing an attacker controls. The attack requires the .git directory to arrive intact as files. That means the risk concentrates in a specific set of workflows:
- Zip archives of "the whole project" sent by a supplier, a customer or a departing consultant.
- Shared drives and sync folders: a SharePoint document library or Teams channel where someone dropped a working copy, synced down to a developer's machine by OneDrive.
- USB sticks and file transfers used to move code across an air gap or between organisations.
- Take-home assignments and PoC code from recruitment processes and vendor evaluations, which arrive precisely from people you have not vetted yet.
Anyone who has worked in a Swedish enterprise will recognise the second item as the uncomfortable one. Code moves between organisations here as SharePoint links and Teams attachments constantly, because that is what the information-security policy blesses for file exchange. For this vulnerability class, the blessed channel is the dangerous one and the plain git clone is the safe one.
What to do this week
- 1. Patch the agents you allow. Claude Code at 2.1.196 or later, Codex CLI at 0.131.0 or later, Goose at 1.44.0 or later, Cursor current. If you manage developer machines with Intune or similar, this is an inventory query plus a forced update, not a project.
- 2. Treat unpatched agents as unsafe on untrusted code. Hermes Agent, Qwen Code and Grok Build were unpatched at disclosure. If they are in use anywhere in your organisation, restrict them to repositories cloned from your own remotes until fixes ship.
- 3. Make "code enters via clone" a rule. Received an archive? Push it through a remote first: unpack on a disposable machine, delete the
.gitdirectory, init fresh, push to your own Azure DevOps or GitHub org, and let developers clone from there. The deletion step strips every repository-supplied config key, not justfsmonitor. - 4. Inspect before you open. When a directory with an intact
.gitmust be opened directly, read.git/configfirst. Manifold's guidance is blunt: any setting that names a program can run it.core.fsmonitorandcore.hooksPathare the obvious keys, but treat the whole file as executable content. - 5. Put an OS boundary around agents that touch third-party code. A dev container, a throwaway VM or a Dev Box that you reset afterwards limits what a triggered payload can reach. The agent's own permission model, as this disclosure shows, is not the boundary.
- 6. Give your detection team the pattern. A
gitprocess spawning a shell or an unexpected child binary on a developer workstation is a specific, monitorable event. Defender for Endpoint custom detection rules handle this well, and the false-positive rate is manageable because legitimate fsmonitor daemons are rare and nameable.
Vendors have a cheaper fix available than most of the above, and Manifold spells it out: sanitize the config on background context-gathering calls, for example git -c core.fsmonitor=false status. The -c flag overrides the repository's value for that invocation. When you evaluate coding agents from now on, whether the tool does this is a fair and answerable security question to put to the vendor.
The Swedish and EU angle
This lands on the NIS2 desk, not the AI Act desk. It is tempting to file anything involving AI agents under AI-regulation, but GitSpawn is ordinary supply-chain code execution. For organisations in scope of NIS2, the relevant obligations are the ones you already carry: supply-chain security measures, vulnerability handling, and incident reporting to your supervisory authority with CERT-SE as national CSIRT if a payload actually fires. The useful compliance question is concrete: does your risk analysis for developer tooling cover the intake of third-party code as files, or only the packages you install and the models you call?
Consultant deliverables deserve a clause. Swedish IT runs on consultants, and consultant engagements end with code changing hands. If your avtal or upphandling templates specify how deliverables are handed over, specify a repository transfer to your own remote rather than an archive. It costs nothing, it produces better provenance anyway, and it removes this entire vulnerability class from the handover. The same applies in reverse: if you deliver code to customers, offering a clean remote transfer is now a small security selling point.
Recruitment code review is exposed. Asking candidates to submit a programming assignment as a zip, then opening it with the same agent-equipped editor you use for production work, is a normal hiring workflow in Stockholm tech. Candidates are, by definition, untrusted third parties. Review submissions in an isolated environment, or require submission via a repository link you clone.
Conclusion
GitSpawn is a good vulnerability to learn from because it is boring. No model jailbreak, no prompt injection, no novel agent behaviour: a twenty-year-old configuration mechanism, a command that runs on index refresh, and a generation of tools that call git in the background without sanitizing what the repository is allowed to tell git to do. Patch Claude Code, Codex, Cursor and Goose now, quarantine the agents still waiting on fixes, and change how archived code enters your organisation. The window between a clean disclosure and the first opportunistic use of it is the cheapest time to act.
subscribe # the AI news that matters, minus the noise