AI AgentsVulnerability ManagementAI Security
Almost every AI agent security story of the past month has been a story about the model. Someone crafted text that persuaded it, fragmented an instruction so it would assemble the attack itself, or gave it a tool it should not have had. The defence, in every case, was some version of making the model behave better.
The research Manifold Security published on September 1, 2026 is not that story. In this one the model is not involved at all. It is not persuaded, not injected into, and in some cases not even authenticated yet. The code runs because the agent shelled out to git, and git did what the repository told it to.
The technique is called GitSpawn. Manifold documented eight findings across seven command-line coding agents, and The Hacker News covered the disclosure on September 3.
Git has a performance setting called core.fsmonitor. It names a helper program that git runs whenever it refreshes the index, so that large repositories do not have to stat every file on every git status. It is a legitimate feature, it is years old, and it is read from the repository's own .git/config.
The rest follows mechanically. CLI coding agents gather project context on startup by quietly running git status and git diff to work out the branch, the dirty files, the diff to summarise. That refreshes the index. Refreshing the index runs the helper. The helper is whatever the repository said it was, and it runs with the full privileges of the logged-in user.
Two properties make this worse than an ordinary "malicious repo" finding:
git, not by the agent's tool layer, so the agent's permission system never sees it. There is no approval prompt, because from the agent's point of view no tool was called.Workspace trust is the control most teams believe they have here — the dialog that asks whether you trust the folder you just opened. GitSpawn executes before you answer it.
This does not fire on a normal git clone. Cloning builds a fresh .git directory locally and does not import the source repository's config. The poisoned .git has to arrive as files.
Manifold's own description of the vector is worth quoting directly: the repository has to arrive with its .git directory already inside, so anything that moves a directory rather than cloning it will do — a shared .zip, a shared drive, a sync folder, a USB stick.
That sounds like a narrowing until you think about how code actually reaches a developer who is being asked to look at something. A vendor sends a reproduction case as an archive. A contractor drops a project folder in Google Drive or SharePoint. A customer attaches a bug repro to a support ticket. An incident responder is handed a copy of a compromised build directory. A candidate submits a take-home. In every one of those flows, someone opens the folder in an agent and says have a look at this — which is precisely the workflow the delivery vector requires.
Manifold reported the findings between 26 June and 20 July 2026 and published on September 1, retesting current versions on that date.
| Agent | Reported on | Status on 1 Sep 2026 |
|---|---|---|
Claude Code (core.fsmonitor) |
2.1.193 | Patched in 2.1.196 |
| OpenAI Codex | July 2026 | Patched — CVE-2026-19592 |
| Cursor | July 2026 | Patched |
| goose | 1.41.0 | Patched in 1.44.0 — CVE-2026-72718 |
| Claude Code (second path) | 2.1.210 | Still vulnerable in 2.1.252 |
| Hermes Agent | 0.18.2 | Still vulnerable in 0.21.0 — CVE-2026-71963 |
| Qwen Code | 0.19.6 | Still vulnerable in 0.22.3 |
| Grok Build | 0.2.93 | Still vulnerable in 1.0.13 |
The second Claude Code finding is the one worth watching. It is a different git configuration key, reached through the agent's ultrareview code path, and Manifold has deliberately not named the key while it remains unfixed. Their report was closed as a duplicate of an internal ticket on 15 July; the behaviour was still present six weeks later. OpenAI's own advisory language for the Codex issue is the clearest summary anyone has given of the class — the helper runs outside the command sandbox and without approval.
Note also what these CVEs are attached to. CVE-2026-72718 belongs to goose. CVE-2026-71963 belongs to Hermes Agent. Two of the eight findings carry a CVE at all, and the unpatched Claude Code path carries none. If your vulnerability process starts with a feed of CVEs, most of GitSpawn is invisible to it — the same structural gap we wrote about when a CVSS 9.8 registry bypass went from patch to exploitation in four days without ever entering CISA KEV.
No in-the-wild exploitation has been documented as of publication.
It is tempting to file GitSpawn next to GhostSplice, the MCP technique that fragments an instruction across channels so the agent assembles the attack itself. They are not the same problem and they do not have the same fix.
GhostSplice is a model problem: the agent read something, reasoned about it, and complied. Every mitigation is therefore about what the model is willing to do — better refusals, better provenance, tighter tool scopes.
GitSpawn is a process problem. The agent is a shell that runs subprocesses, and one of those subprocesses reads untrusted configuration and executes it. Model alignment is irrelevant. Guardrails on the prompt are irrelevant. The only fixes are at the process boundary: the vendor sanitises the environment before shelling out — git -c core.fsmonitor= status — or the developer never lets the poisoned config near the agent.
That distinction matters for anyone building an AI risk register, because the two classes need different owners. One belongs to whoever governs model behaviour. The other belongs to whoever governs what runs on developer endpoints, and it is closer to a supply chain issue than an AI issue.
git config --global core.fsmonitor false. It is worth setting — but be clear that it is not a fix for GitSpawn, because git resolves configuration local-over-global: a value in the repository's own .git/config beats your global one. Only the command-line form wins outright, which is why the vendor-side fix is git -c core.fsmonitor= status. Upgrading the agent is the control here; the global setting is hygiene.git config --get core.fsmonitor, and read .git/config for core.hooksPath and attr.tree while you are in there.Be precise about the boundary first, because this one has a hard edge: nothing in the Obiguard platform prevents a core.fsmonitor helper from executing on a developer's laptop. That exec happens inside git, on an endpoint, before any network call an AI governance layer could see. Anyone telling you their AI security product stops GitSpawn is selling you something. The fixes are the vendor patch and not handing an agent a repository folder you did not clone yourself — apply both.
What is worth governing is the blast radius, and that is a question about where your organisation's AI credentials live.
Consider what a GitSpawn payload is actually for. It gets one shot at arbitrary execution as the developer, so it goes looking for what is portable. The Shai-Hulud worm shows what that shopping list now looks like: GitGuardian found the current variant scanning 469 credential locations, up from 189, and the list has expanded beyond cloud keys and registry tokens to include the local config files of AI clients. The credential sitting in a developer's home directory is now an explicit collection target, and unlike an SSH key it usually has no device binding, no expiry worth mentioning, and no record of where it has been used.
This is the argument for Obichat that has nothing to do with chat features. Obichat is a governed AI workspace where the model providers are connected once, at the workspace level, and employees authenticate through your existing IdP — Okta, Azure AD, any SAML or OIDC provider. The provider credential lives in the deployment, in your cloud or ours; it does not get distributed to every laptop in the company as a file in a home directory. For the large majority of staff who need AI for writing, analysis and research rather than for driving a repository, that removes their machine from the population a credential-stealing payload can profit from at all — and it gives security an exportable activity log per workspace instead of an unknown number of local tools nobody can enumerate. It is the same shadow-AI arithmetic, applied to the endpoint: every local AI tool you did not need is a credential store you did not need.
Developers are the exception, and they should be treated as one rather than pretended away. They will keep running CLI agents, and those agents will keep holding local tokens. For that population, the controls that survive an endpoint compromise are binding and observation: Governance AI issues credentials through allow-lists that tie them to specific models, tools and invoking identities, so a token lifted off a laptop does not work from an attacker's, and the audit ledger gives you a timestamped record to answer what did that key do rather than what could it have done. That is the same lesson as the intrusion where an AI coding agent performed the lateral movement and the operator's own transcript was the evidence — the useful artefact was the log.
The AI security conversation has spent a year on whether models can be trusted to make good decisions. GitSpawn is a reminder that the agent is also a piece of ordinary software running ordinary subprocesses on an ordinary laptop, and that this half of it has been evaluated by almost nobody. Manifold found this by asking a fairly boring question: what do these things actually execute on startup? Eight findings across seven products, four still open six weeks after disclosure, in tools with hundreds of thousands of stars between them.
The model was never the weak part of that story. Nobody was looking at the rest.
Explore Obichat or talk to us about how many machines in your organisation are holding a long-lived model provider credential right now — and whether any of them needed to.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →