The report
A repository can look innocuous when an agent asks Git for its status. In the reference mcp-server-git package, that read-only request could still run a program chosen by the repository being inspected. The November 11 advisory reports a reproducible execution under the MCP server's operating-system identity, while its normal Git status output remained plausible.
The program was inside the data boundary
Git supports configuration values that launch external programs during routine operations. The reference MCP server passed Git commands through GitPython without neutralizing command-bearing settings from a retained .git/config. Consequently, a status or diff request crossed from untrusted repository metadata into process execution, without invoking the coding agent's separate command tool or its approval interface. The advisory demonstrated command execution with a local marker and access to a value present in the server's environment; it did not identify a production victim or prove actual credential theft.
The delivery prerequisite matters. An ordinary Git clone and a normal source-code ZIP do not copy the remote repository's .git/config. The relevant threat is a copied workspace, CI artifact, backup, shared folder or archive that preserves the Git directory. The incident dossier separates that prerequisite from the observed code execution: Git MCP repository-configuration execution.
What changed on November 11
The maintainers list mcp-server-git 2026.11.11 as patched. The fix uses higher-precedence Git configuration overrides, disables unsafe hook and filter behavior for repository-supplied settings, applies safe diff switches and refuses older Git releases that cannot honor the override. Upgrading closes the published path; a text label such as read-only was never an execution boundary by itself. This finding is distinct from the same server's object-store and linked-worktree confinement errors, which require a separate authorization analysis.