CVE-2026-72718

CVE-2026-72718 is a vulnerability in goose's handling of Git operations during context gathering. The issue is a category error about what `git diff` is. The goose team treated it as a read-only introspection command — 'just get me the file names and the diff' — but `git diff` is actually a process that executes inside a Git environment that reads `.git/config` and acts on settings like `core.fsmonitor`. Those settings are attacker-controlled in any cloned repository. The exploit doesn't require a crafted payload delivered through goose's inference pipeline; it requires only that a user run `goose review` on a repository whose config file the attacker wrote at some earlier point. The temporal aspect makes this worse: the command fires before goose contacts any model, before any tool approval gate, before the user has submitted a prompt. There's no opportunity for the human to catch it — the execution happens in the background during context-gathering, completely outside the security model the user is relying on. The second critical design failure is that the Git process inherits the full environment of the goose user. Environment variables — including API keys for LLM providers, cloud credentials, secrets passed through shell RC files — are all available to whatever command `core.fsmonitor` specifies. This isn't a sandbox escape; it's that there was never a sandbox to begin with. The assumption that 'running a local command' is inherently bounded and safe is wrong when that command can recursively invoke other programs with the caller's full privilege level. The fix in 1.44.0 presumably sanitizes the Git environment before invoking git_command(), likely by unsetting or overriding `core.fsmonitor` and potentially other config-driven hooks. But this raises a broader architectural question: how many other commands in goose's codebase assume that executing a system binary is a safe, bounded operation? Any tool that spawns subprocesses and trusts their behavior based on the calling context has this same exposure. The fix patches the wound, but the underlying assumption — that tools are trust boundaries, not environments — deserves scrutiny across the entire codebase. Key questions for defenders: does sanitizing `core.fsmonitor` fully close this vector, or are there other Git config-driven hooks (like post-commit hooks, diff drivers, or filter protocols) that could achieve similar execution? How many other goose commands invoke subprocesses without environmental sanitization, and what would a systematic audit look like? Is there a principled way to define the trust boundary for an AI agent that intentionally runs commands on the user's system — should 'trust the user, distrust the repository' be an explicit security posture?

Reviewed through automated stages and approved by a human before publication.