mcp-server-git Vulnerability: We Tested 7 Repo Config Tricks Against the Fix

Updated November 12, 2026. Lab run on Linux with Git 2.47.3: mcp-server-git 2026.11.4 and 2026.11.11 over stdio, confined with --repository, no network access needed.

A high-severity mcp-server-git vulnerability, GHSA-6hqx-gqrx-c5r2, let a repository’s own .git/config run a program on the host when an AI agent asked for nothing more than git_status. mcp-server-git is the official reference Git server from the Model Context Protocol (MCP) project, and it recorded 175,042 PyPI downloads in the last month. The project shipped the fix on November 11, 2026, in mcp-server-git 2026.11.11, as part of the MCP servers v2.4.0 release that patched six advisories across three servers.

Upgrading to mcp-server-git 2026.11.11 closes the hole: in our November 12 lab, 7 of 7 planted Git settings ran code on 2026.11.4 and 0 of 7 ran on the fixed version. The upgrade does not reach you automatically in three common setups. A uvx mcp-server-git config can keep serving a cached older copy, the mcp/git image on Docker Hub was last updated June 16, 2025, and Git older than 2.31 now makes the server refuse to start a tool call.

What GHSA-6hqx-gqrx-c5r2 Says About mcp-server-git

GHSA-6hqx-gqrx-c5r2 says mcp-server-git ran Git inside repositories chosen by the client without overriding settings in that repository’s own configuration. Git treats several of those settings as commands, so pointing the server at an untrusted repository and calling git_status could execute attacker-chosen code with the server’s privileges.

The advisory was filed through Anthropic’s HackerOne program, tested against mcp-server-git 2026.11.4 and 2026.10.28, and published by maintainer cliffhall on November 11, 2026 at 07:25 UTC. GitHub rates it High with a CVSS 3.1 score of 7.8: local attack vector, low complexity, no privileges, and user interaction required. The reporter’s own CVSS 4.0 vector scores 7.0, which is the figure some coverage quotes.

The report traces the root cause to one line. Before the fix, the only configuration override the server passed to Git was core.quotepath=false, so every other key in .git/config applied. The report places the bug in the class the Cloud Security Alliance named GitSpawn on September 3, 2026, which already has CVEs for GitHub Copilot CLI (CVE-2026-45033), Goose (CVE-2026-72718), and Hermes Agent (CVE-2026-71963).

How a Read-Only git_status Call Ran Attacker Code

A read-only git_status call ran attacker code because Git refreshes its index during git status, and an index refresh runs whatever program core.fsmonitor names. The repository supplies that value, so the repository decides what runs, and the MCP tool only has to look.

core.fsmonitor is a Git setting that names a file system monitor program Git asks for a list of changed files, to speed up status checks in large repositories. diff.external and diff.<driver>.textconv name programs Git runs to produce or transform diffs. Filter drivers and hooks name programs Git runs when files are staged or branches change.

mcp-server-git marks git_status, git_diff_unstaged, git_diff_staged, git_diff, and git_log with the MCP readOnlyHint annotation. The hint tells clients the tool does not change anything, which is why users tend to approve such calls without review, and models call git_status early to orient themselves in a project. The advisory notes that the code runs inside Git, not through the model’s own command tool, so the client’s confirmation dialog and sandbox never see it.

What We Found When We Tested 7 Git Config Sinks

We found that all 7 repository settings we planted executed code on mcp-server-git 2026.11.4, and none executed on 2026.11.11. Every call returned a normal result on both versions, and confining the server with --repository made no difference on the old release.

Our lab installed both versions from PyPI with uv, started each one over stdio with --repository pointing at a workspace, and called one tool against a repository nested inside it. Each payload appended a line to a marker file that included the value of MCP_LAB_CANARY, an environment variable that existed only in the server process. A control repository with no planted setting ran nothing on either version.

Three results go beyond the advisory’s proof of concept. With diff.external or a textconv driver planted, the old server returned an empty diff for a file we had changed, so a payload could hide its own edits from the model reviewing them. An include.path entry that pulled core.fsmonitor from a second file inside .git worked the same as setting it directly. An inline value, core.fsmonitor = sh -c '...', needed no payload file at all.

On 2026.11.11, the same seven repositories produced no marker, the two diff tools returned the real patch, and git_add and git_checkout completed normally. The fix passes its overrides through GIT_CONFIG_COUNT environment variables, which outrank every configuration file including included ones, and it adds --no-ext-diff and --no-textconv to every diff the server shows.

Who Is Actually Exposed to This mcp-server-git Vulnerability

You are exposed if an agent running mcp-server-git 2026.11.4 or earlier opens a repository whose .git directory came from someone else. A plain git clone does not copy the remote’s .git/config or hooks, so cloning a stranger’s project from GitHub does not deliver this payload.

The advisory lists the channels that do carry a .git directory intact: project archives and CI artifacts, backups, shared network folders, vendored dependency trees unpacked beside a project, and agent workspaces copied rather than cloned. GitHub’s source ZIP downloads exclude .git. Coverage that tells readers a stranger’s clone is enough overstates the reach, and a write-up that calls this remote command execution misreads the local attack vector in GitHub’s score.

The impact is still serious where the condition holds. The payload inherits the server’s environment, which often includes tokens passed through the MCP client’s env block, and it can read SSH keys, cloud credentials, and every repository the user can reach. On a CI runner or a shared agent host, it runs as that account.

The Other Five Advisories in MCP Servers v2.4.0

The other five advisories in MCP servers v2.4.0 are a moderate git confinement bypass, two moderate filesystem symlink races, and two low-severity fetch bugs. All six were published on November 11, 2026 within about four minutes of each other, and none had a CVE ID when we checked on November 12.

Advisory	Package and fixed version	Severity (CVSS 3.1)	What it allowed
GHSA-6hqx-gqrx-c5r2	mcp-server-git 2026.11.11	High (7.8)	Repository Git config ran programs during read-only tools
GHSA-q74p-4wrc-q7w6	mcp-server-git 2026.11.11	Moderate (5.3)	Incomplete fix for GHSA-w766-5×43-whvw: alternates and linked worktrees escaped --repository
GHSA-7m4x-rv66-mxhh	server-filesystem 2.3.0	Moderate (5.0)	move_file race moved an outside file into allowed directories
GHSA-p9cv-8g75-4xcg	server-filesystem 2.3.0	Moderate (4.4)	Symlink swap after validation let read_text_file read outside allowed directories
GHSA-3rxj-6jhw-qfv7	mcp-server-fetch 2026.11.11	Low (3.1)	IPv6 site-local fec0::/10 treated as public by the SSRF guard
GHSA-f9hh-cmx9-2f23	mcp-server-fetch 2026.11.11	Low (3.1)	//private style paths bypassed robots.txt rules

The filesystem fix has a version trap. The TypeScript servers moved from date versions such as 2026.8.31 to semantic versions at 1.0.0, and package managers rank 2.3.0 below every 2025.x and 2026.x version, so anyone on a date version must install @modelcontextprotocol/server-filesystem@2.3.0 explicitly. The release notes also say the read fix only narrows the race on Windows, and the git confinement fix does not yet cover Windows directory junctions.

Why the Fix Arrived 3 Days After a Public Issue

The fix arrived 3 days after a public issue because a second researcher filed the same bug in the open. Issue #5488, opened November 8 at 15:51 UTC, described core.fsmonitor and hook execution through mcp-server-git tools, and it was closed about 11.5 hours later, with no patched release until November 11.

Fix pull request #5514 opened November 11 at 04:41 UTC and merged at 06:18, adding 945 lines across 5 files, 491 of them in a new test_repository_config.py regression suite. PyPI received 2026.11.11 at 07:09 UTC and the advisory went live at 07:25. That is the 7th security advisory for mcp-server-git since December 2025 and the first rated High.

What mcp-server-git Users Should Do Now

mcp-server-git users should confirm that the server actually running is 2026.11.11 or later, then check every place a client launches it, since an MCP config, a cached uvx environment, and a Docker image can each hold a different version of the same server.

1. Pin the version in each MCP config, for example uvx mcp-server-git==2026.11.11, or use mcp-server-git@latest. The uv documentation says uvx keeps using a cached tool version after the first run unless a version is requested or the cache is refreshed.
2. Stop using the mcp/git image from Docker Hub until it is rebuilt. Its only tag, latest, was last updated June 16, 2025 and has 200,878 pulls. Build the image from the repository’s src/git Dockerfile at v2.4.0 instead.
3. Run git --version on every host and container that runs the server. The fixed server refuses Git older than 2.31, because older Git ignores GIT_CONFIG_COUNT.
4. Search repositories your agents opened for fsmonitor, diff.external, textconv, filter., and hooksPath entries, and for executable files in .git/hooks, with special attention to unpacked archives and shared folders.
5. Rotate tokens passed to mcp-server-git through the client’s env block if a vulnerable version opened a repository you did not create.
6. Upgrade @modelcontextprotocol/server-filesystem to 2.3.0 and mcp-server-fetch to 2026.11.11 in the same change.

Choose the plain upgrade when mcp-server-git only ever opens repositories you cloned yourself, because a fresh clone carries no remote configuration. Choose the upgrade plus a repository audit and token rotation when agents open archives, CI artifacts, or shared folders, because those are the channels the advisory names. Keep --repository set in both cases: it does not stop this bug, but it limits which repositories a prompt-injected agent can reach.

Where This Fits in MCP Server Security

GHSA-6hqx-gqrx-c5r2 joins a run of agent-side code execution flaws in our news coverage this month where a trusted default did the damage. The fast-agent CVE-2026-102610 test showed a served agent with no authentication, and the AgentScope MCP workspace flaw showed arbitrary MCP commands in another framework.

For the client side of the same problem, see the MCP redirect vulnerability in mcp-go and the MCP Inspector 2.14.0 security fixes. Teams picking Git and filesystem servers can compare options in our MCP servers guide, and coding agents that shell out to Git are covered in our AI coding agent security tools roundup. For controls in front of servers, see the MCP security tools guide and the MCP gateways roundup.

FAQ