A routine Git check becomes the trigger

Security researchers have disclosed GitSpawn, a class of weaknesses in which a malicious project directory can cause code to run as soon as an AI coding agent examines it. The victim does not have to submit a prompt or approve a tool call. In some affected products, execution can occur during startup and even before authentication, turning a seemingly passive act—opening a project—into a local compromise.

The underlying behavior begins with context collection. Coding agents commonly run commands such as git status or git diff to understand the state of a repository. Those commands may refresh Git's index. Git also supports core.fsmonitor, a performance option that can point to a helper program, and its value can be read from the repository's own .git/config file. A prepared directory can therefore arrange for Git to launch an attacker-controlled command during that automatic refresh.

Why ordinary cloning is not the delivery route

The attack has an important constraint: a conventional git clone, fetch, or pull does not transfer a hostile .git/config file. An attacker instead needs to deliver the repository with its internal .git directory intact. Plausible routes include a ZIP archive, synchronized folder, shared drive, removable device, or a copied project tree handed between colleagues and contractors.

That limitation reduces mass exploitation through public hosting platforms, but it maps well to real development workflows. Teams regularly exchange reproductions, customer projects, consulting handoffs, and archived source trees outside normal cloning. A convincing project can also target a particular developer, whose account may hold source-code access, cloud credentials, signing keys, or production deployment privileges. The payload inherits the logged-in user's rights and can operate beyond an AI agent's intended sandbox or approval controls.

Multiple agents affected, with mixed patch status

Manifold Security reported confirming related behavior across Claude Code, Goose, Hermes Agent, Qwen Code, and Grok Build. Variants were also reported in Codex and Cursor, and both vendors issued patches after independent discoveries. Goose fixed its issue, tracked as CVE-2026-72718. Hermes received CVE-2026-71963 after researchers said repeated disclosure attempts received no response.

Four of eight tracked issues were reportedly still unpatched when the research was published. One separate Claude Code path involved another Git configuration key connected to an ultrareview function; researchers withheld that key to avoid providing an immediate attack recipe. The breadth of products matters because the weakness is not a single parser bug. It is a trust-boundary failure created when automated developer tools execute repository-aware commands before treating the project as hostile input.

Defensive steps for developers and tool makers

Developers should treat project folders received as archives or copied directories as untrusted executables. Before opening one in an agent or IDE, remove the supplied .git directory when history is unnecessary, or inspect .git/config in a controlled environment. Re-create the repository metadata from a trusted remote where possible. Teams should also avoid opening unsolicited reproduction packages on workstations that contain production secrets.

Agent vendors can reduce exposure by sanitizing Git configuration for background commands, explicitly disabling risky helpers such as core.fsmonitor, delaying repository inspection until trust is established, and presenting a clear approval boundary before any subprocess can run. Endpoint defenders should look for unexpected child processes spawned by Git or coding-agent processes, especially immediately after a new folder is opened. Updating affected tools remains essential, but the longer-term lesson is broader: repository metadata must be handled as attacker-controlled content, not harmless context.

Practical security takeaway

This event also underlines the importance of layered controls and rehearsed incident response. Organizations should document ownership for identity, endpoint, cloud, and developer tooling; retain the telemetry needed to connect activity across those systems; and test containment procedures before an emergency. Security teams should translate vendor guidance into measurable checks rather than treating an update or configuration change as the end of the investigation. Where exposure is possible, defenders should establish a time window, identify affected assets and accounts, preserve relevant evidence, and verify that remediation actually removed persistence. Users and administrators should rely on official update channels, avoid unverified fixes, and report suspicious behavior promptly. These steps cannot eliminate every attack path, but they reduce both the likelihood that an initial foothold succeeds and the damage an intruder can cause after gaining access.