MCP Vulnerability Triage: Match the Advisory, Usage Path, and Mitigation
An official mcp-server-git advisory affected versions before 2026.1.14 through git_add path handling. Triage requires the deployed version, reachable tool path, process-visible files, and verified upgrade or isolation evidence.
Read in JapaneseA security advisory becomes an adoption decision only after three links are established: the advisory matches the deployed artifact, the affected usage path is reachable, and the mitigation is present in that deployment. The official mcp-server-git advisory GHSA-vjqx-cfc4-9h6v provides a concrete example. It reports that versions before 2026.1.14 allowed git_add file arguments containing ../ to resolve outside the repository and enter the Git index. Version 2026.1.14 is listed as patched.
Key findings
- The affected version range is narrower than “all Git MCP servers.” The advisory names the pip package
mcp-server-gitbefore2026.1.14. - The relevant path is narrower than “all Git operations.” The published defect concerns file paths supplied to
git_add. - Impact depends on subsequent authority. Staging an outside file becomes more serious when commit, push, credentials, or sensitive host files are reachable.
- A source update is not deployment evidence. Acceptance requires the patched artifact or a tested control in the running environment.
Triage record
| Question | Evidence to collect | Decision effect |
|---|---|---|
| Is the artifact affected? | Installed package name and exact version inside the real environment | A different package or 2026.1.14+ does not match this advisory's affected range |
| Is the path reachable? | Whether the client exposes git_add and which users or agents may call it | An unreachable tool lowers exposure but does not patch the artifact |
| What can the process see? | Repository path, mounts, OS user, readable files, Git credentials | Defines which outside files and later commit/push actions are possible |
| Is mitigation deployed? | Package version, image digest or lock, restart record, and rejection test | Supports closure for this advisory |
The advisory describes potential exfiltration through a later commit and push. That sequence matters: git_add changes the index, while disclosure depends on another operation and a destination. Triage should therefore record both the immediate boundary failure and the available follow-on operations. It should not downgrade the defect merely because commit or push requires another call, and it should not claim confirmed disclosure when no outside file was staged or transmitted.
Bounded acceptance test
Use a disposable repository and a harmless sibling file. Pin and install mcp-server-git 2026.1.14 or later in the same image or Python environment used for deployment. Invoke the normal in-repository add path and confirm it works. Then pass a relative path that resolves to the harmless sibling and verify that the request is rejected before the file enters the index. Inspect the index, not just the tool's text response.
Reduce authority even after the upgrade. Run the server with access only to the intended repository, keep unrelated credentials and files outside its view, and limit push credentials to the approved destination. Those controls reduce consequences from future defects or configuration mistakes; they do not replace the package update when the affected version is present.
Limits
This triage is based on the official advisory and project material reviewed on September 22, 2026. It is not evidence that a particular organization runs an affected version or suffered data exposure. It covers the published git_add path issue, not every advisory in the repository, every Git argument, or the intended side effects of write-capable Git tools. The official servers project also describes its servers as reference implementations rather than production-ready solutions, so production acceptance requires a deployment-specific threat model and controls.