A Git Setting Nobody Audits
Manifold Security disclosed a technique it calls GitSpawn that turns an obscure but entirely legitimate Git configuration option into a code execution primitive against AI coding agents. The setting is core.fsmonitor, a performance feature that tells Git to run an external command to quickly identify which files in a repository have changed, rather than scanning the whole tree. Git reads this setting straight out of the repository's own .git/config file, and it will happily execute whatever command that file specifies.
That design has existed for years without being a meaningful security problem, because a human developer typically clones a repository from a known remote before opening it, and the config file travels through a trust relationship with that remote. AI coding agents changed the calculation. They routinely inspect repositories that arrive by other means, and they run background commands like git status or git diff automatically, without a human first deciding whether the repository itself is trustworthy.
The Attack Beats Every Safeguard You Built In
The specific mechanics are what make this worth an engineering leader's attention rather than a footnote in a vulnerability feed. When an AI agent opens a folder to work on it, it commonly runs a quick background git command to establish branch state and file changes before doing anything else. If that folder's .git/config carries a malicious core.fsmonitor entry, the agent triggers it during that routine check, and the researchers found this happens before workspace-trust prompts are accepted, before user authentication, on the very first keystroke of interaction, and entirely outside whatever sandbox the agent vendor has built.
Every layer of protection a security team might point to as the reason AI coding agents are safe to deploy broadly, sandboxing, trust prompts, permission gating, sits downstream of the trigger point GitSpawn exploits. As the researchers put it, the vulnerability is not in the model or in anything new, it lives in the ordinary plumbing underneath: the subprocess an agent spawns at session startup just to work out where it is. That framing matters because it means better prompting or model alignment does nothing to close this gap. It is an engineering fix, not a training fix.
Patched, Unpatched, and In Between
The disclosure landed unevenly across the AI coding agent market. Goose fixed the issue in version 1.44.0. Claude Code patched the core.fsmonitor path in version 2.1.196, though a related worktree-operations flaw tracked separately as CVE-2026-55607 persisted past that release. Cursor and Codex both shipped fixes, with Codex's coming across CLI, macOS desktop, and Windows desktop builds. OpenAI independently discovered and disclosed the same underlying class of vulnerability in Codex and issued three of its own CVEs on the same day Manifold published, which is itself a useful signal that this was not a single researcher's edge case but a real, findable flaw sitting in shared architectural assumptions across the category.
As of the disclosure, Hermes Agent, Qwen Code, and Grok Build had not shipped fixes. If your engineering organization has standardized on one of these tools, or lets developers choose freely among agent vendors, you now have a concrete reason to check patch status by product and version rather than assuming the category as a whole has caught up. Sonar had flagged a related issue back in April 2026, which means this general risk pattern in agent tooling was known well before Manifold's more complete disclosure, and vendors had months of lead time to close the gap before it became public.
How This Actually Reaches Your Developers
The exploitation path is more mundane than a typical zero-day narrative, which is exactly why it deserves attention. GitSpawn requires the .git directory to arrive intact, a condition a zip archive, a shared drive folder, a cloud sync tool, or a USB stick satisfies easily, even though a standard git clone through a trusted remote does not carry the same exploitable configuration state. Think about how often a developer on your team pulls down a sample repository from a vendor, a contractor's starter project, a conference demo, or a colleague's shared folder, then opens it in an AI-assisted editor to see what it does. Every one of those ordinary actions is a plausible delivery mechanism.
No confirmed exploitation in the wild had been documented as of the disclosure, and the CVEs involved did not appear in CISA's Known Exploited Vulnerabilities catalog at the time. That is genuinely good news, but it describes a narrow window, not a closed one. The technique is now public, documented in enough detail to replicate, and sitting in front of an attacker population that has shown consistent interest in developer tooling as an initial access vector over the past two years.
The Governance Gap AI Coding Tools Exposed
Most enterprise rollouts of AI coding agents focused governance energy on output risk: hallucinated dependencies, leaked secrets in generated code, license contamination from training data. GitSpawn is a reminder that the input side carries its own attack surface, and that surface activates before the agent produces a single line of code or asks for permission to do anything. A developer does not need to accept a suggestion or approve an action for this to fire. Opening the folder is enough.
The concrete step available today, regardless of which agent vendor you use, is disabling core.fsmonitor globally with a single git config command, and pushing that as a baseline setting across every developer machine running an AI coding assistant. Beyond that immediate mitigation, engineering leaders should ask their AI tooling vendor directly which of these CVEs apply to the version currently deployed, and build a habit of treating any repository that did not come through your own controlled clone process as untrusted input, worthy of inspection before an agent ever touches it.
