The Repository Is the Payload, and Opening It Is the Exploit

On 1 September 2026 Manifold Security published a vulnerability class it calls GitSpawn: eight findings across seven AI coding agents, in which a repository can execute attacker supplied commands on a developer machine the moment that repository is opened with an agent. No prompt is typed. No approval dialog is clicked. In some configurations it fires before the user has even authenticated to the agent. The affected list is not a set of obscure projects: Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build and Hermes Agent. Four of the eight findings were patched by publication and four were not. Two carry CVE identifiers, CVE-2026-72718 against Goose at severity 7.0 and CVE-2026-71963 against Hermes Agent, the latter assigned by VulnCheck acting as an independent numbering authority rather than by the vendor. If your engineering team uses any of the coding tools we list in the AI Coding category, this is a live item for the week rather than background reading.

The mechanism is almost disappointingly ordinary, which is what makes it worth understanding. Git has a performance setting called core.fsmonitor whose value is a command. Git runs that command to work out which files changed, and it runs it during an index refresh. Every AI coding agent examined gathers context by quietly executing routine git operations in the background, git status and git diff being the obvious ones, so that it can tell you what branch you are on and what you have modified. If the agent does not neutralise repository controlled configuration before making those calls, the repository decides what git executes. The .git/config file inside the folder you opened is, functionally, a script that runs on open. OpenAI made the sharpest observation in its own CVE text: the helper runs outside the command sandbox and without a user approval prompt, which means the two controls most teams believe they have over agent behaviour are simply not in the path.

The delivery constraint is the detail that decides how worried you should be, and it is the detail most of the coverage buried. A hostile .git/config does not travel over the wire. Clone, fetch and pull do not transmit it, so pointing an agent at a malicious URL on a public forge does not deliver this attack. The repository has to arrive as files with its .git directory intact: a zipped archive attached to an email, a folder on a shared drive, a synced directory, a contractor handover, a USB stick, a Docker build context copied wholesale. That narrows the blast radius considerably, and it also names an everyday workflow that almost nobody treats as untrusted input. Reviewing a candidate take home exercise, opening a client codebase delivered as an archive, unpacking a vendor sample project, restoring a folder from a sync tool: each of those is now an execution event if an agent touches it first.

What makes GitSpawn a class rather than an incident is where the trust boundary turned out to be. Most of the security work around coding agents over the last two years has pointed at the model: prompt injection, poisoned instructions in a README, malicious content retrieved mid task, the whole category we covered when we wrote about agent data injection. GitSpawn involves no model at all. There is no natural language, no probabilistic behaviour, no clever phrasing that might or might not persuade a system. It is deterministic code execution triggered by a configuration file, and it works identically whether the agent behind it is a frontier model or a stub. The lesson generalises past git. Any file an agent reads to orient itself in a workspace, and any tool it shells out to in order to do that, is an input channel from whoever wrote that workspace. Editor configuration, build files, task definitions, hook scripts and language server settings are all in the same category, and they were all designed in an era when opening a folder was an inert act.

The vendor response is the second story and arguably the more useful one. Manifold reported these findings between 26 June and 20 July 2026 and published on 1 September. Five reports were closed as duplicates of independent submissions, which tells you several researchers found the same thing at roughly the same time. One vendor never triaged its report despite six separate contact attempts. Anthropic fixed the core.fsmonitor path in Claude Code on 29 June but published no advisory, so a team running that product had its security posture changed underneath it with no signal, and a second path in the same product remained unfixed at publication. OpenAI issued CVEs. Goose fixed in 1.44.0, Codex CLI in 0.131.0 and Codex Desktop in 26.519. Read that spread carefully, because it is the actual finding for anyone managing a fleet: patch state, disclosure practice and advisory discipline vary enormously between AI tooling vendors, and if your process for learning that a tool changed is waiting for the vendor to tell you, you will be told late or never.

The remediation splits cleanly into what vendors must do and what you can do today. The vendor side fix is one flag: sanitise the git configuration on the context gathering calls the product makes in the background, for example by invoking git -c core.fsmonitor=false status rather than plain git status. That is not a difficult change, which is part of why four unpatched findings at publication is a fair thing to be annoyed about. On your side, three actions are available immediately. Update every agent in use to a version at or beyond the fixed releases, and record which ones have no fix available yet. Inspect .git/config before opening any repository that reached you as files rather than through a clone, and if that inspection sounds like something nobody will actually do, then prefer the stronger version: do not open received archives at all, clone from the canonical origin instead and treat the archive as a diff to compare against. Audit global and system level git configuration on developer machines while you are there, because a hostile value set once at the global scope does not need a poisoned repository to keep working.

Mapping this into a compliance programme is straightforward, and it is the kind of mapping that pays for itself the next time an auditor asks how you manage developer tooling. Under ISO 27001, this sits in endpoint protection, secure development and supplier relationships all at once: the agents your developers install are software running with their privileges on machines holding your source, and an inventory that stops at operating system and browser is not an inventory. Under SOC 2, an agent that silently changed security behaviour in a background release is a change management event you did not capture, and the honest answer to that is a monitored version currency control rather than a policy sentence. Under ISO 42001, each agent earns an entry with its version, its patch state against known findings, who approved it and what it is permitted to touch. The compliance automation platforms we cover, Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof, will all carry version currency and endpoint software as monitored controls once configured. What none of them will do is discover that half your team installed a coding agent last quarter without telling anyone, and shadow agent installation is by a wide margin the most common failure in this area.

There is a broader pattern here that connects to most of what we have written about agent security this year. The tools are moving faster than the assumptions underneath them. Cursor, GitHub Copilot, Claude Code, Codex and Devin all won adoption by removing friction from the developer workflow, and one of the frictions they removed was the moment where a human decided that a piece of code was worth executing. An agent that reads your repository to be helpful is running code on your behalf continuously, and the interface gives you no visual distinction between reading and running. The same structural problem shows up in application builders such as Bolt, v0 and Lovable, where a generated project arrives as a folder that somebody then opens locally, and in any workflow where an ElevenLabs or ChatGPT integration is handed to you as a starter template to unzip. The fix is not to stop using agents. It is to stop treating a directory as data.

The work this week is short. List every AI coding agent actually installed across your engineering team, not the one your standards document says you use, and check each against the fixed versions. Flag Qwen Code, Grok Build and Hermes Agent specifically, since those were unpatched on 1 September and you should confirm current status before assuming otherwise. Write a one line rule that repositories received as archives get cloned from origin instead of opened, and put it where developers will actually see it rather than in a policy nobody reads. Add agent versions to whatever inventory you already maintain. And if your team learned about GitSpawn from this post rather than from a vendor advisory, that gap is the finding worth acting on, because the next disclosure in this class is already being written and it will reach you the same way.