The Model Isn't the Problem — the Harness Is
It's worth being precise about what this path goes around. An agent's permission system governs what the model wants to do: whether to allow a file write, a shell command, a network call. But nothing here is executed by the model. It's a git subprocess the agent's own code spawns to gather context. `core.fsmonitor` is a documented git feature, and it reads from the repository's own `.git/config`, so at no point in the chain does the model have to say anything — which is why no approval prompt appears and the sandbox does not apply. What the attacker gets is arbitrary code execution as the developer: SSH keys, cloud credentials in the environment, tokens in shell configuration, every repository on disk, and a durable foothold.
The Delivery Constraint Decides Who Is Actually at Risk
There's an easily overlooked limitation here that is the single most useful thing to remember: a normal `git clone`, `fetch` or `pull` cannot deliver this attack, because those operations never transfer a repository's `.git/config`. A poisoned repo has to reach you as files, with its `.git` directory already inside. So the exposure isn't "I cloned an unfamiliar repository." It's zip archives, shared drives, sync folders and USB sticks — precisely how contractors deliver work, how colleagues hand over a project, and how a client sends code for review. People are habitually far less suspicious of a zip a coworker sent than of an unfamiliar GitHub link.
What to Do Now
Three checks you can run today: see whether the current repo has the setting planted with `git config --get core.fsmonitor`; turn it off globally if you'd rather not audit one by one, `git config --global core.fsmonitor false`; and before opening any externally delivered folder, inspect `.git/config` for `core.fsmonitor`, `core.hooksPath` and filter-related settings — or simply delete the `.git` directory first. The vendor-side fix is straightforward: strip the configuration during background context gathering, e.g. `git -c core.fsmonitor=false status`. On Manifold's timeline, Claude Code's `core.fsmonitor` path was reported June 26 and fixed in 2.1.196; Cursor (July 8), Goose (July 13, fixed in 1.44.0, CVE-2026-72718) and Codex (July 20, with three separate CVEs from OpenAI) are also handled. Still open are Qwen Code, Grok Build, Hermes (CVE-2026-71963), and the Claude Code `ultrareview` issue that abuses a different config key — reported July 15, closed as a duplicate of an internal ticket, and confirmed still triggerable on 2.1.252 on September 1, with the researchers deliberately withholding the key name. One piece of good news: as of September 2 nobody has reported exploitation in the wild, and none of these identifiers appear in CISA's Known Exploited Vulnerabilities catalog. For this class of issue the window usually opens after disclosure, which makes right now the cheapest moment to act.
via: Manifold Security technical disclosure, The Hacker News, Cybersecurity News