GitSpawn: AI Coding Agent Git-Config RCE

On 2026-09-01, Manifold Security disclosed GitSpawn: a vulnerability class affecting seven AI coding agents (Claude Code, OpenAI Codex, Cursor, Goose, Hermes Agent, Qwen Code, Grok Build) across eight distinct findings. Every one of these agents gathers project context by quietly running git status / git diff in the background: often before the user has typed a prompt, accepted a workspace-trust dialog, or authenticated. Git supports core.fsmonitor, a legitimate performance setting naming a helper program that git launches automatically whenever it refreshes its index. That value is read straight out of the repository's own .git/config. A malicious repository can set it (or the related core.hooksPath, attr.tree, or a clean/process filter command) to an attacker-chosen program, and the moment the agent's background git command touches that repo, the program runs: as the logged-in user, outside the agent's sandbox, and invisible to the agent's own permission/approval system.

Four of the eight findings were still unpatched at publication (Claude Code's second "ultrareview" path, Hermes Agent, Qwen Code, Grok Build). Two formal CVEs anchor the disclosure: CVE-2026-19592 (OpenAI Codex CLI/Desktop, CVSS 7.3, fixed 0.131.0) and CVE-2026-72718 (Goose, fixed 1.44.0). A related, separately-tracked Claude Code vulnerability, CVE-2026-55607 (git-worktree path confusion abusing the same fsmonitor execution sink, CVSS 8.8, fixed 2.1.163), shares the mechanism but a different delivery chain (requires a clone plus prompt-injection content, not merely opening a received folder): see §2 for the reconciliation.

Delivery reality: this cannot arrive via an ordinary git clone, fetch, or pull, since none of those transmit a hostile .git/config. The repository has to arrive as files with its .git directory already inside, exactly how developers routinely receive projects: a zipped project handoff from a contractor, a synced cloud-drive share, a "bug report" archive from a stranger, or a USB stick.

Defender priority: there are no published C2 domains, IPs, or file hashes for this research: the atomic surface is configuration strings and affected agent version numbers, not infrastructure, and the sensor cannot see the contents of a git config file it did not observe being written. The hunt is therefore behavioral: unexpected process ancestry (agent → git → shell/interpreter/network tool), archive extraction immediately preceding a git/agent launch, and the follow-on credential-access and persistence an attacker would chase once code execution lands. Patch/version-pin every affected agent (§12) and inspect .git/config in any repository received as files before opening it in an agent.

Reconciliation note: CVE-2026-55607 is related but distinct: Manifold's GitSpawn disclosure says Claude Code's core.fsmonitor path was fixed in 2.1.196 (with a second "ultrareview" path reportedly still live at 2.1.252). CVE-2026-55607 was fixed earlier, in 2.1.163, via a different delivery chain: cloning a malicious repo containing prompt-injection content that steers the agent into vulnerable worktree operations, not simply opening a received folder. This pack cites CVE-2026-55607 for its fsmonitor-abuse detection and hardening value (§6, §9, §12) while keeping its version numbers and delivery chain clearly separate from the GitSpawn-labeled Claude Code findings.

IOC provenance note: no cited source publishes atomic infrastructure indicators (attacker IPs, C2 domains, malware hashes) for GitSpawn: the "indicators" are affected-version strings and the git config keys themselves. §10's Falcon IOC Management CSV block is therefore placeholder-only by design; §4 and §10's behavioral/config blocks are the operative content.

The exploit itself is nothing more than a few text lines in a file the victim already has on disk. All of the detectable behavior happens after an AI coding agent's routine background git command reads that file and launches whatever it names.

Hunt hypotheses (highest fidelity first)

Attack chain

No cited source publishes atomic infrastructure indicators (attacker IPs, C2 domains, malware file hashes) for GitSpawn. The "indicators" that exist are affected-component version numbers and the git configuration keys the attack abuses: both are config/behavioral, and both trace directly to the saved source snapshots. Atomic-IOC rows are intentionally omitted rather than fabricated.

There is no attacker infrastructure to hunt for and no C2 domain/IP/hash to import. The single most valuable action for this pack is inventorying which AI coding agents run on which endpoints, at which versions (§10's audit block): that inventory is what turns §8's queries from "any git process" into "a specific unpatched agent's git process."

These checks give you ground truth on exactly what Falcon cannot see: the actual contents of a repository's .git/config, and which AI coding agent build is installed. Run before, or alongside, the CQL in §8.

Inspect a received repository before opening it in an agent (any platform)

git config --get core.fsmonitor
git config --get core.hooksPath
git config --get attr.tree
grep -nE "fsmonitor|hooksPath|\[filter" .git/config .gitattributes 2>/dev/null
# Any output naming an external program is a hold-and-review, not an open-in-agent.

Vendor-recommended safe context-gathering (per Manifold / The Hacker News)

# Strip the sink on any ad hoc background git command:
git -c core.fsmonitor=false status
git -c core.fsmonitor=false diff
# Set a permanent default until every agent in use is confirmed patched:
git config --global core.fsmonitor false

Inventory installed AI coding agent versions (run fleet-wide via RMM/MDM)

claude --version
codex --version
cursor --version
goose --version
grok-build --version 2>/dev/null
qwen-code --version 2>/dev/null
# Compare output against the affected/fixed table in Section 4 and the audit block in Section 10.

macOS-specific: confirm sandbox/seatbelt profile is current (CVE-2026-55607 surface)

• Confirm Claude Code is at 2.1.163+ (CVE-2026-55607) and 2.1.196+ (GitSpawn core.fsmonitor path): both are required; they are different fixes.
• Review ~/.zshenv, ~/.zprofile, and ~/.bash_profile for unexpected recent modification timestamps.

Q3, Q4, Q7, and Q9 are best run as scheduled searches / investigate-only, not endpoint Prevent IOAs: Q3 matches the vendor's own recommended mitigation command, and Q4/Q7/Q9 use host-level time-window correlation that needs a tenant-specific tuning pass before it can safely block.

L1 triage checklist (for a Q1/Q2/Q6 hit)

1. Confirm the AI coding agent's installed version against the affected/fixed table in §4: is this endpoint actually running a vulnerable build?
2. Pull the full command line and working directory of the flagged git process; identify the repository path.
3. If the repository is reachable, inspect its .git/config and .gitattributes for core.fsmonitor, core.hooksPath, attr.tree, or filter commands (§7).
4. Identify how the repository arrived: git log/reflog will show no clone history for a files-delivered repo; check Downloads, sync-folder, or USB provenance.
5. Check the flagged host for Q5 (credential access), Q7 (outbound connections), Q8/Q9 (persistence) hits in the same window.
6. If the helper program executed, treat the endpoint as compromised: rotate any credentials the logged-in user could reach (SSH keys, cloud tokens, git-credential store, saved API tokens).
7. Isolate the host via Falcon RTR pending investigation; preserve the offending repository folder for analysis rather than deleting it.
8. Patch/upgrade the agent to a fixed version (§12) before returning the host to service.

Pivot queries

• Host-scoped: re-run Q1, Q5, Q7, Q8, Q9 filtered to the single flagged aid over the preceding 24h to reconstruct the full session.
• Environment-wide: re-run Q4 (archive-extraction → git/agent) across all developer endpoints for the prior 7 days to check for other deliveries of the same repository.

No atomic infrastructure IOCs are published for GitSpawn, so the Falcon IOC-Management block below uses REPLACE_WITH_* placeholders: populate only from confirmed incident evidence (a recovered helper binary, observed C2). The behavioral, config-key, and version-audit blocks are the operative content for this pack.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_HELPER_BINARY_HASH,detect,high,2027-03-25,GitSpawn fsmonitor/hooksPath helper (confirm in incident),campaign:GitSpawn
domain,REPLACE_WITH_C2_DOMAIN,detect,high,2026-12-25,GitSpawn post-exploit C2 (confirm in incident),campaign:GitSpawn
ipv4,REPLACE_WITH_C2_IP,detect,high,2026-12-25,GitSpawn post-exploit callback (confirm in incident),campaign:GitSpawn
# NOTE: no atomic infrastructure IOCs were published for GitSpawn -- do NOT import blank rows.
# ACTION COLUMN: every row ships at "detect", matching the Section 4 action vocabulary.
#   A hash you recovered from your own confirmed incident is the only row worth raising to
#   "prevent", and only after you have verified the binary is not a renamed legitimate tool.
#   Never raise the domain or ipv4 rows to "prevent" on one observation: post-exploit
#   callbacks land on shared and reassigned hosting, so a prevent-mode block there can cut
#   legitimate traffic. No gate downstream re-checks this column, so it is yours to own.

# GitSpawn behavioral indicators
# 1. AI coding agent binary as grandparent of git, which is parent of a shell/interpreter
# 2. git spawning a child that is not one of its documented helper binaries
# 3. git invoked with an explicit "-c core.fsmonitor=" / "-c core.hooksPath=" / "-c attr.tree=" override
# 4. Archive-extraction tool run immediately before a git/agent process launch, same host
# 5. Process descended from git touching SSH keys, cloud credential files, or git-credential stores
# 6. git worktree created named/pathed ".git" (path-confusion, CVE-2026-55607-class)
# 7. Outbound network connection from a shell/interpreter descended from git
# 8. Shell-profile/dotfile (.zshenv, .bash_profile, .profile) rewritten by a git/agent-descended process

# Settings a repository's own .git/config can weaponize (GitSpawn sinks):
core.fsmonitor      # names a helper git runs automatically on every index refresh
core.hooksPath       # redirects git's hook directory to an attacker-controlled path
attr.tree             # names a tree-ish used to resolve .gitattributes -- can be abused
                      # in combination with clean/process/smudge filter commands
filter.<name>.clean   # arbitrary command run by "git add" for matching paths
filter.<name>.process # arbitrary long-running command run by git for matching paths
# Presence of ANY of these naming an executable/script in a received repo = hold and review.

# Per-endpoint audit: is the installed agent version fixed for GitSpawn?
claude --version      # need 2.1.196+ (fsmonitor path) AND 2.1.163+ (CVE-2026-55607, worktree)
codex --version        # need 0.131.0+ (CLI) / 26.519.22136+ (macOS) / 26.519.21041+ (Windows)
goose --version         # need 1.44.0+ (CVE-2026-72718)
cursor --version         # confirm patched build per vendor release notes (no version disclosed publicly)
qwen-code --version       # UNPATCHED at publication -- treat as vulnerable regardless of version
grok-build --version       # UNPATCHED at publication -- treat as vulnerable regardless of version
hermes-agent --version      # UNPATCHED at publication -- treat as vulnerable regardless of version
# Any repo-inspection command from the "grab-keys" block above should run before opening
# a received (non-cloned) folder in any of the above, especially the still-unpatched agents.

Playbook A: Disable the fsmonitor sink fleet-wide (Windows / macOS / Linux, shell)

Prerequisites: git 2.x installed; ability to push a global gitconfig change via RMM/MDM/Ansible to developer endpoints. Reboot required: none. Rollback: re-enable with git config --global core.fsmonitor true (or remove the line from the global gitconfig) once every agent in the fleet is confirmed patched.

# 1. Push to every developer endpoint's per-user git global config
git config --global core.fsmonitor false

# 2. Verify it took effect
git config --get core.fsmonitor
# expect: false

# 3. (Optional, stronger) also neutralize the other reported sinks globally where supported by your git version:
git config --global core.hooksPath ""
# Rollback: git config --global --unset core.fsmonitor
#           git config --global --unset core.hooksPath

Playbook B: Version-pin and upgrade affected agents

Prerequisites: package-manager or installer access for each agent (npm/pip/brew/winget/direct installer); a maintenance window is not required since these are user-space CLI tools, but active agent sessions should be closed first. Reboot required: none for CLI agents; Codex Desktop / Cursor (Electron apps) require the application to restart, not the OS. Rollback: pin back to the prior version only if the upgrade breaks a workflow: re-exposes the vulnerability, so pair any rollback with Playbook A staying active.

# Claude Code -- confirm BOTH fixes are present (they are different bugs):
npm install -g @anthropic-ai/claude-code@latest   # need >=2.1.196 AND >=2.1.163
claude --version

# OpenAI Codex CLI -- need >=0.131.0
npm install -g @openai/codex@latest
codex --version

# Goose -- need >=1.44.0
# (use your platform's Goose install/update mechanism; verify via)
goose --version

# Unpatched at publication -- Hermes Agent, Qwen Code, Grok Build:
# no fixed version exists yet. Apply Playbook A (disable core.fsmonitor) and
# Playbook C (repo intake review) as compensating controls until a fix ships.
# Rollback: revert to the previously pinned package version via your package
# manager's install-specific-version syntax if the new build breaks a workflow.

Playbook C: Repository intake review (any platform received as files, not cloned)

Prerequisites: none beyond a shell and git itself; suitable for a pre-commit-style local script or a SOAR/EDR RTR script triggered on archive extraction. Reboot required: none. Rollback: none required: this is a read-only inspection step with no persistent system change.

#!/usr/bin/env bash
# Run against any repository that arrived as a zip/tar/synced-folder/USB copy
# (never needed for a plain "git clone" -- that path cannot carry these settings).
REPO_DIR="$1"
cd "$REPO_DIR" || exit 1
echo "== Checking $REPO_DIR/.git/config and .gitattributes for named-program sinks =="
grep -nE "fsmonitor|hooksPath|\[filter" .git/config .gitattributes 2>/dev/null
if [ $? -eq 0 ]; then
  echo "HOLD: this repo's config names an external program -- review before opening in any AI coding agent."
  exit 1
fi
echo "No known GitSpawn sink strings found. Still confirm agent version against Section 4/10 before proceeding."

Playbook D: Safe-directory scoping (git >=2.35.2, all platforms)

Prerequisites: git version supporting safe.directory (2.35.2+, effectively all currently-supported git releases). Reboot required: none. Rollback: git config --global --unset-all safe.directory restores git's prior implicit-trust behavior.

# Scope trust to explicitly-approved project roots instead of trusting every
# directory git is pointed at (reduces the set of folders where an agent's
# background git command will silently operate on an unreviewed .git/config):
git config --global --add safe.directory /Users/*/projects/*
git config --global --add safe.directory C:/Users/*/source/*
# Verify:
git config --get-all safe.directory
# Rollback: git config --global --unset-all safe.directory

Known gap: there is no way to detect a malicious .git/config value purely from its presence on disk with EDR telemetry: the sensor sees the process that reads it (the git launch) and the process it spawns, not the file's contents. This pack closes that gap behaviorally (§8 Q1–Q3) rather than via file-content inspection, and closes it operationally via the intake-review playbook (§13C) that DOES read the file. Validation gates for all CQL are in §11.

Generated 2026-09-25 · HuntPack pipeline (web-hunter-v2 → threat-hunter-v2 → crowdstrike-logscale-v3 → alert-builder-v2 → threat-hardening-v2 → review-v2) · Defensive content only.