Git MCP Repository Boundaries: Align --repository with Every Tool Call
A published mcp-server-git vulnerability failed to enforce that each repo_path stayed within the repository selected at startup. Acceptance requires resolved-path containment, verified launch configuration, and narrow process access.
Read in JapaneseOn December 17, 2025, the official Model Context Protocol servers project published an advisory about repository restriction in the pip package mcp-server-git. Before 2025.12.18, an operator could start the server with --repository to select one repository, yet later tool calls did not verify that their repo_path remained inside that configured path. A call could therefore operate on another repository reachable by the server process.
The failed boundary sat between administrator intent at startup and the target supplied on each call. A launch argument such as --repository /work/approved does not force every tool request to repeat that path. Unless the server compares the two, the setting documents an intention without enforcing it.
Repository containment in the patch
The official patch resolves both the configured repository and the requested repo_path to physical paths. It then uses path-component containment to require that the requested path equal the configured repository or be below it. The check runs before the server opens the requested Git repository. Resolving first also prevents a symlink that appears in scope from redirecting the request to another repository.
| Review point | Insufficient evidence | Acceptance evidence |
|---|---|---|
| Launch command | Example in documentation | Running process received --repository and the intended absolute path |
| Tool request | repo_path names a Git repository | Resolved path equals or is a true descendant of the configured repository |
| Symlink | Visible path appears in scope | Destination after resolution remains in the allowed repository |
| Distributed artifact | Recent container tag | Package inside the image or Python environment is a patched release at or after 2025.12.18 |
| Host exposure | Server-side validation alone | Mounts and OS permissions hide unrelated repositories |
The advisory has a specific configuration condition: it concerns deployments using --repository. The official patch adds containment when that flag is set and preserves prior behavior when it is absent. Upgrading the package therefore does not automatically select an allowed repository. If the deployment requires a repository boundary, include the explicit flag in the real launch command and verify that the running process received it.
A bounded adoption test
Create two harmless test repositories. Confirm that the permitted repository supports the status, diff, log, or mutation operations required by the workflow. Then supply the sibling repository as repo_path and verify rejection before any Git operation. Include a symlink inside the allowed area that points to the sibling. Keep the results tied to the deployed package and launch command, because a source-code review alone does not establish runtime configuration.
Reduce process authority as a second enforcement layer. A review-only workflow may support a read-only mount. If commit or checkout is required, make only the intended repository writable and prevent the same account from reading unrelated projects or credentials. Application containment and operating-system permissions address different failure modes; retain evidence for both.
If several repositories are required, avoid widening one process to a broad parent directory without reviewing the consequence. Separate server instances or purpose-specific mounts can make each allowed set explicit. The right arrangement depends on whether cross-repository operations are part of the approved workflow.
Scope and limitations
This analysis uses the official advisory, patch, and README reviewed on September 22, 2026. It is not an MCP Guard discovery or a finding about a specific current deployment. Current impact requires the actual pip package version, launch-time --repository value, callers allowed to invoke tools, and filesystem visible to the process. The patch governs repository selection; it does not independently address option interpretation in Git arguments, secrets stored inside the allowed repository, or intended side effects of mutating tools.