GitSpawn: failure that allows you to run commands from .git / config on IA tools

An independent research team, Manifold Security, has published a report that describes a class of vulnerability present in various programming assistance tools based on artificial intelligence: if a received repository includes its .git directory with a malicious configuration, the configuration itself can indicate a command that the tool runs on the developer's team. out of the safe and without asking for confirmation. Manifold called the collection of findings "GitSpawn" and documented eight operating routes on seven command line agents; at the time of their last verification several routes remained unpatched. At the same time, OpenAI published CVE (s) that describe a problem of the same nature in its Codex product.

Technically, the root is the interaction between how Git stores certain options in the .git / config file of a repository and how automated agents invoke Git operations in the background. An adjustment in Git called chore.fsmonitor can contain a command that Git runs to accelerate the detection of changed files; Git reads that value from the repository's own .git / config. When an agent needs to know the current branch or which files have changed it runs operations like git status or git diff: these commands trigger the execution of the binary configured in chore.fsmonitor. If that value points to an executable controlled by an attacker, the command runs with the same privileges of the user and outside the restricted environment of the agent.

The operating requirement for the operation is for the receiver to obtain the working tree along with its .git folder intact - for example through a shared compressed file, a synchronized network drive, a synchronization folder or a USB memory -; according to reports, in such situations the malicious configuration is kept. Manifold indicates that a standard "clone" does not preserve exactly the same condition in all cases identified by the researcher, and therefore does not always expose the user, but the above-mentioned delivery scenarios do.

What products and versions are affected (confirmed by Manifold and / or by public advisories): goose (all versions prior to 1.44.0, corrected in 1.44.0); Codex CLI and Codex Desktop (range of affected versions and corrections published up to 0.131.0 / specific building numbers for macOS / Windows); Claude Code (chore.fsmonitor route mitigated in 2.1.196, but another route called "claude ultrarevieew" was confirmed active in 2.1.252); CLI Cursor (documented by Mandold with execution prior to the trust dialogue); Hermes Agit, Qwen and Grok, also executed in the recent - rebound patch as well as reperformed in the recent - repository in the repository. OpenAI published at least one CVE (CVE-2026-19592) that describes the same pattern in Codex; GitHub assigned CVE-2026-72718 to the goose failure with a reported CVSS rating.

The practical effects are clear and severe: the execution of commands with user privileges allows an attacker to read, modify or delete local files, steal credentials, exfilter secrets (tokens, SSH keys) and generally take unauthorized steps in the local environment. Manifold documented cases in which execution even occurs before the user sees or accepts the "workspace trust" dialog, or even before the user becomes self-aware in the agent - conditions that make the risk worse because they eliminate human mitigation phases.

Confirmed facts: Manifold has published technical details and concept tests on several routes; some suppliers already sent patches for specific routes (e.g. goose, Claude Code and Cursor parts); OpenAI published CVE (s) applicable to Codex. There are no verified public records of exploitation in nature related to these findings up to the date of the above-mentioned public checks, and the list of known vulnerabilities exploited by CISA did not include these CVE in its last review.

Estimates and elements still uncertain: Manifold points out that the pattern appears in more agents than he has appointed; that suggests that the actual scope could be greater, but a complete public enumeration is not available. There is imprecise on which later versions (in particular Claude Code for the second route) have already solved all the routes: Manifold confirmed the second route still active in the 2.1.252, and there was no universal public confirmation of closure in releases after the time of the report. Also, in some cases, the suppliers closed reports as duplicates of parallel investigations, which complicates drawing a unique and public time line of mitigation.

Why this happens now: is not a failure of the IA model, but of the "plumbing" - the calls to the system that agents launch at the start of a session to detect context of the repository -. Modern automatic tools call Git in the background to identify branch and changes; Git, by design, allows to run hooks or configurable collaborative processes. This flexibility of Git, combined with automation, makes a legitimate feature a local remote execution vector.

What a developer or team should do right now (concrete and verifiable actions): inspect any directory received before opening it with an IA agent; check fsmonitor and suspicious values settings; disable fsmonitor by default if not necessary; and update the affected tools to the parched versions. Useful commands (run in a safe environment): open and review .git / config in any directory received; rungit config --get chore.fsmonitorinside the repo to see an active value; audit the global configuration withgit config --global --list ∞ 124; grep fsmonitorand, where appropriate, deactivate by default withgit config --global chore.fsmonitor false. Sellers mitigate in some cases by invoking Git in background with a flag that overrides the dangerous variable, e.g.git -c chore.fsmonitor = false statusa recommended practice until patches are confirmed.

Additional operational recommendations: not open folders received from unreliable origin on an IDE or agent with unrestricted access without prior inspection; use isolated environments (virtual machines or containers) when exploring third-party repositories; keep up-to-date customer tools (check and apply versions that suppliers have published as a patch); and, for equipment, audit code exchange flows (compression, folder synchronization, use of external disks) to prevent malicious .git from spreading accidentally.

Reference resources and technical context: the official documentation of the Git configuration on options such as chore.fsmonitor explains the purpose and format of that key - see https: / / git-scm.com / docs / git-config-. To place this pattern in a background, previous vulnerabilities related to the bypass of the trust dialogue in editors and environments have been catalogued (e.g., CVE-2021-43891), the record of which can be found in https: / / cve.mitre.org / cgi-bin / cvename.cgi? name = CVE-2021-43891. CISA maintains a catalogue of known exploited vulnerabilities that should be reviewed periodically to see if active holdings emerge: https: / / www.cisa.gov / knowledge-exploited-vulnerabilities-catalog.

Conclusion: The vulnerability described by Manifold does not require manipulated models or IA failures; it exploits the combination of Git flexibility and agent automation. Although several suppliers have already corrected specific routes, there are still open vectors in key tools and the actual exposure depends on how the repository developers receive (e.g. shared files or external units). Until the tools are all parched and the practice of invoking Git in the background is consistently safe, the most effective defense is prior inspection, preventive deactivation of chore.fsmonitor and the use of isolated environments to analyze unknown code.