# Our coding agent uses the official MCP git server (mcp-server-git from the modelcontextprotocol/servers repo). If the agent runs git_status or a diff on a repository we downloaded, unpacked or were sent, can that repository run a program on our machine, and does the November 11, 2026 release fix it?

**Short answer:** Yes, before mcp-server-git 2026.11.11. Advisory GHSA-6hqx-gqrx-c5r2 (high, CVSS 3.1 7.8, published November 11, 2026) shows that the server ran Git inside whatever repository the client named without overriding that repository's own .git/config. Git runs the program named in core.fsmonitor whenever it refreshes the index, so a call to the read-only git_status tool (and git_diff_unstaged, git_add and git_merge) ran an attacker-chosen command with the MCP server's user, files and environment, including any credentials passed in the client's env block, with no approval prompt and with or without --repository. The report also lists diff.external, hooks, filter drivers and commit signing as routes through other tools, and demonstrated diff.external the same way. The payload has to arrive with its .git folder intact (an archive, a backup, a CI artifact, a shared folder, a vendored or copied tree); a plain git clone and GitHub's source ZIP don't carry a repository's .git/config. Upgrade to 2026.11.11, which forces those settings off for every Git command it runs and refuses Git older than 2.31. The advisory lists no workaround other than upgrading; until then, only point the server at repositories whose .git folder you trust.

## Checklist
1. Find every MCP client config that starts mcp-server-git (uvx, pip, Docker or a pinned path) and check the version it resolves to. Anything before 2026.11.11 is affected; the report confirmed 2026.10.28 and 2026.11.4 and presumes earlier versions are too.
2. Upgrade to mcp-server-git 2026.11.11 or later (published on PyPI at 2:09 AM ET on November 11, 2026) and pin the version you reviewed instead of letting uvx pick latest.
3. Check the Git on that machine: the fixed server refuses Git older than 2.31, because older Git ignores the GIT_CONFIG_COUNT variables the fix relies on.
4. Until you've upgraded, don't let the agent run any git tool on a folder that arrived with its .git directory from somewhere else: an unpacked archive or CI artifact, a restored backup, a shared drive, a vendored dependency tree or a workspace copied from another agent.
5. Before trusting such a folder, read its .git/config yourself (or run git config --local --list) and look for core.fsmonitor, core.hooksPath, diff.external, any diff.<name>.command or textconv, filter.<name>.clean/smudge/process and gpg.program.
6. Don't count on Git's safe.directory check: it only refuses repositories owned by another user, and a folder you unpacked yourself is owned by you.
7. Keep secrets out of the git server's env block. Whatever that process can read, a repository-supplied command could read before the fix.
8. If the server runs with --repository on Windows, read the companion advisory GHSA-q74p-4wrc-q7w6: the confinement fix doesn't yet recognise directory junctions inside a Git directory.
9. Run the git server in a sandbox or container with only the repository it needs and no network, so the next bug in this class runs with as little as possible.

## How can a repository's .git/config run a program through mcp-server-git's git_status tool?
- Git reads configuration from the repository's own .git/config as well as your global settings, and some keys name a program for Git to run. core.fsmonitor names a hook command Git calls to learn which files changed, so it fires on any index refresh, including a plain git status. The advisory's table maps each key to the server tools that triggered it: core.fsmonitor through git_status, git_diff_unstaged, git_add and git_merge; diff.external and diff.<driver>.command through the diff tools; core.hooksPath with hooks, and commit.gpgSign with gpg.program, through git_merge; filter.<driver>.clean through git_add.
- Before the fix, the only setting the server overrode was core.quotepath. The report's proof of concept set core.fsmonitor to a script inside the repository, called git_status over stdio and got a normal-looking status result while the script recorded the server's user ID, an environment variable only the server process had, and a file outside the repository. The command can also be written inline in the config line, so one edited .git/config is enough.
- This runs outside whatever approval or sandbox your client applies to the model's own shell commands: the client sees a read-only status call, and the program runs inside the MCP server process. The report notes the same class had already been reported against other agent tools that shell out to Git.

## What does the mcp-server-git 2026.11.11 fix for GHSA-6hqx-gqrx-c5r2 change?
- The fix (pull request 5514) sets overrides through GIT_CONFIG_COUNT, which Git's documentation says outranks values in configuration files and which Git passes to the Git processes it starts itself: core.fsmonitor false, core.hooksPath pointed at the null device so no hook runs, commit.gpgSign and merge.verifySignatures false, submodule.recurse, status.submoduleSummary and merge.autoStash false, and core.pager set to cat.
- Filter drivers, merge drivers and branch.<name>.mergeOptions defined by the repository's own configuration are emptied; drivers from your global or system configuration, such as Git LFS, keep working. git_merge also passes --no-gpg-sign and --no-verify-signatures, patch-style diffs pass --no-ext-diff and --no-textconv, and git_status and the diff tools pass --ignore-submodules=dirty so Git doesn't read a submodule's own configuration.
- What it doesn't change: the server still runs with your user's access to every file and secret its process can reach, and it is still a reference implementation. A Git setting nobody has listed yet, or a bug in the server's own code, runs with the same reach, which is why the sandbox and the empty env block still matter after the upgrade.

## What else did the November 11, 2026 MCP reference server advisories fix in the git, filesystem and fetch servers?
- The same release fixed GHSA-q74p-4wrc-q7w6 (medium): with --repository, a caller who could write plain files inside the allowed repository could read objects from another repository through objects/info/alternates, or reach a main repository's index and HEAD through a nested .git file inside a linked worktree. It affects 2026.10.28 up to 2026.11.11 (earlier versions are covered by the October 28 advisory). The fix refuses alternate object stores under --repository and symbolic links in a Git directory that lead outside it; Windows directory junctions aren't recognised yet.
- The filesystem server got two medium advisories fixed in @modelcontextprotocol/server-filesystem 2.3.0 (published on npm November 11, 2026): a symlink swapped after validation let read_text_file return a file outside allowedDirectories, and move_file's same-device rename could move a file from a swapped source folder. The old date-based versions (2025.1.14 through 2026.8.31) have no patched release. mcp-server-fetch 2026.11.11 fixed two low-severity gaps: IPv6 site-local fec0::/10 addresses treated as public by the private-address guard, and paths such as //private fetched while robots.txt disallowed /private.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "My agent wants to run git_status on a repository it unpacked from a vendor's archive into vendor/acme-sdk. Ask me to approve that exact call first, with a record I can check, because the repository arrived with its .git folder."

```json
{
  "tool": "request_human_approval",
  "arguments": {
    "action": {
      "tool": "git_status",
      "server": "mcp-server-git",
      "repo_path": "vendor/acme-sdk",
      "source": "unpacked vendor archive with .git",
      "server_version": "2026.11.11"
    },
    "summary": "Run git_status on vendor/acme-sdk (unpacked archive, .git included)",
    "expires_in_minutes": 30
  }
}
```
- Needs a key for your account. It hashes the action details and returns an approval id and a one-time token for the owner. Only the account owner can decide it, with an account key; delegated agent keys are refused, so the agent can't approve its own request. Anyone can check the signed decision free with verify_human_approval, including that the action matches what was approved.
- It doesn't open the repository, read its .git/config, check your mcp-server-git or Git version, or stop a call your client sends straight to the git server. It only covers calls your agent or harness routes through it first, so upgrade the server and read the config yourself before approving.

_Rightshold isn't affiliated with the Model Context Protocol project. It doesn't scan repositories, MCP server code or local configuration, and an approval record isn't a finding that a repository is safe. Advisory details are as published in the modelcontextprotocol/servers repository on GitHub on November 11, 2026, Git behavior as described in Git's documentation, and release dates as listed on PyPI and npm, all read November 11, 2026; advisories get updated, so confirm fixed versions on the linked pages._

## Sources
- [modelcontextprotocol/servers: GHSA-6hqx-gqrx-c5r2, mcp-server-git arbitrary command execution via a repository's own Git configuration (core.fsmonitor)](https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-6hqx-gqrx-c5r2)
- [modelcontextprotocol/servers: GHSA-q74p-4wrc-q7w6, incomplete fix for GHSA-w766-5x43-whvw allows --repository confinement bypass](https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-q74p-4wrc-q7w6)
- [modelcontextprotocol/servers: GHSA-p9cv-8g75-4xcg, symlink swap after validation lets read_text_file return files outside allowedDirectories](https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-p9cv-8g75-4xcg)
- [modelcontextprotocol/servers: security advisories](https://github.com/modelcontextprotocol/servers/security/advisories)
- [Git documentation: git-config (core.fsmonitor, safe.directory, GIT_CONFIG_COUNT)](https://git-scm.com/docs/git-config)
- [PyPI: mcp-server-git release history](https://pypi.org/project/mcp-server-git/)

## Related
- [Which versions of the official MCP git, filesystem and fetch servers are safe to run?](https://www.rightshold.com/answers/which-versions-of-the-official-mcp-git-filesystem-and-fetch-servers-are-safe-to-run)
- [How to sandbox a local stdio MCP server to only the files and hosts it needs](https://www.rightshold.com/answers/how-to-sandbox-a-local-stdio-mcp-server-to-only-the-files-and-hosts-it-needs)
- [How to keep API keys and tokens out of mcp.json and Claude Desktop config files](https://www.rightshold.com/answers/how-to-keep-api-keys-and-tokens-out-of-mcp-json-and-claude-desktop-config-files)
- [Can connecting to a malicious remote MCP server run code on my machine?](https://www.rightshold.com/answers/can-connecting-to-a-malicious-remote-mcp-server-run-code-on-my-machine-mcp-remote-cve-2025-6514)

_Not legal advice. Updated 2026-11-11. JSON: https://www.rightshold.com/answers/can-opening-an-untrusted-repository-with-the-mcp-git-server-run-code-on-your-machine.json_