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?

What should I check, step by step?

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.