Deployment-specific remediation guidance for security practitioners.

Quick Remediation

If you’re using uvx (the recommended installation method):

# Clear the Tool cache
uv cache clean

# Next run will pull latest from PyPI


Note: In some cases, even if the MCP configuration references uvx, the tool may have been installed separately on the system. If so, uvx will use the already-installed version. Check which installation method applies to your specific case.

If you installed via uv tool install:

#Verify the installed version
uv tool list | grep -i mcp-server-git

# Upgrade to latest
uv tool upgrade mcp-server-git
# or, if a pinned version was installed previously
uv tool install --force mcp-server-git

# Alternatively, uninstall and reinstall
uv tool uninstall mcp-server-git
uv tool install mcp-server-git

#Verify the installed version
uv tool list | grep -i mcp-server-git


If you installed via pip:

# Check current version
pip list | grep mcp-server-git
# or the equivalent uv pip
uv pip list | grep mcp-server-git

# Upgrade to latest
pip install --upgrade mcp-server-git
# or the equivalent uv pip
uv pip install --upgrade mcp-server-git

# Check current version
pip list | grep mcp-server-git
# or the equivalent uv pip
uv pip list | grep mcp-server-git


If you’re using Docker:

The official mcp/git Docker image is still vulnerable - it’s stuck on a pre-patch version from approximately June 2025. You have three options:

1. Switch to uvx (recommended - add this to your MCP client config and configure the path appropriately):
2. {
 "mcpServers": {
   "git": {
     "command": "uvx",
     "args": ["mcp-server-git", "--repository", "/path/to/your/workspace"]
   }
 }
}

3. Limit Docker scope to only your current workspace (temporary workaround):
4. {
 "mcpServers": {
   "git": {
     "command": "docker",
     "args": [
       "run", "--rm", "-i",
       "--mount", "type=bind,src=/path/to/workspace,dst=/path/to/workspace",
       "mcp/git"
     ]
   }
 }
}

5. Replace /path/to/workspace with your actual project path. In VSCode, you can use ${workspaceFolder} if supported.
6. Build a patched Docker image yourself (see Dockerfile at the end of this post).

Target version: 2025.12.18 or later (current latest: 2026.1.14)

Why This Matters

Three vulnerabilities were disclosed on January 20, 2026. Path traversal, argument injection, unrestricted repository initialization. When chained together through prompt injection, they achieve remote code execution.

Most coverage focuses on the threat: AI agents are risky, prompt injection is dangerous, even reference implementations have bugs. All true. But that doesn’t help if you’re the one who needs to actually patch your deployment.

The CVE disclosures say “upgrade to 2025.12.18 or later.” The documentation suggest to “install via uv or pip” or configure it using Docker.

Neither tells you that uvx might be serving a vulnerable cached version, or that the Docker image hasn’t been updated. This post fills that gap.

The Installation Complexity Nobody Talks About

mcp-server-git can be deployed five different ways, each with its own update mechanism:

1. uvx (ephemeral execution)
2. uv tool install (persistent installation)
3. pip install (traditional Python package)
4. Docker (containerised)
5. From source (git clone + manual build)

The CVE disclosures simply say “upgrade to 2025.12.18 or later.” The official documentation doesn’t explain how to upgrade across these different installation methods. And as we discovered, the Docker image hasn’t been updated at all.

Let’s walk through each method’s technical details.

Method 1: uvx (Ephemeral Execution)

How uvx Actually Works

When you run uvx mcp-server-git, the uv tool:

1. Creates a temporary isolated virtual environment in its cache directory
2. Installs the latest available version from PyPI
3. Executes the tool
4. Keeps the environment cached for future runs

The cache is persistent - it’s not truly ephemeral in the sense of “recreated every time.” This means if you first ran uvx before December 2025, you’re likely still running a vulnerable cached version.

Cache Locations

Linux/macOS: ~/.cache/uv (or $XDG_CACHE_HOME/uv)

Windows: %LOCALAPPDATA%\uv\cache

Verify with: uv cache dir

The Remediation Commands

# Option 1: Clear cache for mcp-server-git specifically
uv cache clean mcp-server-git

# Option 2: Clear entire uv cache (nuclear option)
uv cache clean

# Option 3: Force refresh on next run
uvx --refresh mcp-server-git


After clearing the cache, the next time your MCP client invokes the server, uvx will download and cache the latest version (2026.1.14 as of this writing).

Automatic Update Checking

If you want uvx to check for updates on every run (trading performance for always-current versions), modify your MCP config:

{
 "mcpServers": {
   "git": {
     "command": "uvx",
     "args": ["mcp-server-git@latest", "--repository", "/path/to/repo"]
   }
 }
}


Using mcp-server-git@latest tells uvx to check PyPI for newer versions and upgrade if available. This adds latency to startup but ensures you’re always running the latest patched version.

Method 2: uv tool install (Persistent Installation)

How This Differs from uvx

uv tool install creates a permanent installation in your tools directory (typically ~/.local/share/uv/tools), with executables added to your PATH. This is different from uvx’s cache-based approach. uvx will refer to this installation from now on.

Tools Directory Location

Verify with: uv tool dir

Expected output:

‍~/.local/share/uv/tools (Linux/macOS)

or %LOCALAPPDATA%\\uv\\tools (Windows)

The Remediation Commands

# Check if mcp-server-git is currently installed
uv tool list | grep mcp-server-git

# Option 1: Upgrade in place
uv tool upgrade mcp-server-git

# Option 2: Uninstall and reinstall
uv tool uninstall mcp-server-git
uv tool install mcp-server-git

# Verify version (check output from uv tool list)
uv tool list | grep mcp-server-git


Important: Running uv cache clean does not affect tools installed via uv tool install. These are separate systems.

Method 3: pip install (Traditional Python Environment)

This is the most straightforward installation method, but also the one most likely to be forgotten during updates.

The Remediation Commands

# Check current version
pip show mcp-server-git

# Upgrade to latest
pip install --upgrade mcp-server-git

# Verify version
pip list | grep mcp-server-git


Configuration Example

{
 "mcpServers": {
   "git": {
     "command": "python",
     "args": ["-m", "mcp_server_git", "--repository", "/path/to/repo"]
   }
 }
}


Method 4: Docker  (Official Image Outdated)

Image Maintenance Gap

The official mcp/git Docker image on Docker Hub contains version mcp_server_git-0.6.2, which is several versions behind the latest release in the official repository and hasn't been updated since approximately June 2025.

That’s months before these vulnerabilities were patched. Users following the official deployment guide are running vulnerable code without knowing it.

Why Docker Updates Matter (and Don’t)

Docker does provide scope isolation, which is its primary security value. The mount configuration limits which host directories the container can access and this alone goes in the direction of mitigating the effects of  the reported path traversal vulnerability:

{
 "mcpServers": {
   "git": {
     "command": "docker",
     "args": [
       "run", "--rm", "-i",
       "--mount", "type=bind,src=/Users/username,dst=/Users/username",
       "mcp/git"
     ]
   }
 }
}


However, if you’ve configured src to a top-level directory (like /Users/username as in the original documentation or worse, /), the vulnerabilities are just as exploitable as without Docker.

Three Remediation Paths

Option A: Switch to uvx (Recommended)

Replace your Docker configuration with:

{
 "mcpServers": {
   "git": {
     "command": "uvx",
     "args": ["mcp-server-git", "--repository", "/path/to/workspace"]
   }
 }
}


Pros: Always pulls latest patched version, no container overhead, simpler configuration.

Cons: Requires uv installed on the host system.

Option B: Restrict Docker Mount Scope (Temporary Workaround)

Limit the mount to only your current workspace:

{
 "mcpServers": {
   "git": {
     "command": "docker",
     "args": [
       "run", "--rm", "-i",
       "--mount", "type=bind,src=${workspaceFolder},dst=${workspaceFolder}",
       "mcp/git"
     ]
   }
 }
}


This reduces the attack surface but doesn’t eliminate the vulnerabilities - it just limits what an attacker can reach.

Option C: Build Your Own Patched Docker Image

Until the official image is updated, you can build a patched version yourself. Here’s a minimal Dockerfile that replicates the original image structure while installing the latest mcp-server-git:

# Dockerfile for patched mcp-server-git
FROM python:3.12-slim-bookworm

# Install git
RUN apt-get update && \\
   apt-get install -y --no-install-recommends git && \\
   rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Create virtual environment and install latest mcp-server-git
RUN python -m venv /app/.venv && \\
   /app/.venv/bin/pip install --no-cache-dir mcp-server-git>=2025.12.18

# Update PATH to use venv
ENV PATH="/app/.venv/bin:$PATH"

# Set entrypoint
ENTRYPOINT ["mcp-server-git"]


Build and use:

# Build the image
docker build -t mcp-git-patched:latest .

# Update your MCP config to use the patched image
{
 "mcpServers": {
   "git": {
     "command": "docker",
     "args": [
       "run", "--rm", "-i",
       "--mount", "type=bind,src=/path/to/workspace,dst=/path/to/workspace",
       "mcp-git-patched:latest"
     ]
   }
 }
}


To update in the future:

docker build --no-cache -t mcp-git-patched:latest .


Understanding the Vulnerabilities (The Technical Details)

Now that we’ve covered remediation, here’s what you’re actually fixing.

CVE-2025-68145: Path Validation Bypass (CVSS 6.4)

The --repository flag was supposed to restrict mcp-server-git to operations within a specific directory. The validation logic failed to properly resolve paths, allowing attackers to use absolute paths or ../ traversal sequences to access repositories outside the intended scope.

Attack example:

# Intended operation:
--repository /home/user/project
repo_path: /home/user/project/safe-repo  ✓

# Bypass:
--repository /home/user/project
repo_path: /etc/secrets  ✗ (Should fail but didn't)


The fix: Added proper path resolution with symlink following and containment verification.

CVE-2025-68144: Argument Injection (CVSS 6.3)

The git_diff and git_checkout functions passed user-controlled arguments directly to Git without sanitisation. Attackers could inject Git command-line flags disguised as git refs.

Attack example:

# Intended: git diff main feature
# Malicious: git diff --output=/tmp/steal.txt main

# The --output flag gets interpreted by Git, not as a ref name


The fix: Reject any argument starting with -, and validate all arguments resolve to actual git refs via rev-parse.

CVE-2025-68143: Unrestricted git_init (CVSS 6.5)

The git_init tool accepted arbitrary filesystem paths with no validation, allowing repository creation anywhere the server process had write access. This enabled attack chains like:

1. git_init /tmp/malicious-repo
2. Use Filesystem MCP to write malicious scripts
3. Configure git hooks or filters to execute those scripts
4. Trigger execution via git operations

The fix: The entire git_init tool was removed. The MCP server is now intended to operate only on existing repositories.

The Compound Attack Chain

It was demonstrated how these vulnerabilities chain with the Filesystem MCP server to achieve remote code execution:

1. git_init creates a repository in a writable location
2. Filesystem MCP writes a malicious bash payload
3. git config (via argument injection) sets up clean/smudge filters pointing to the payload
4. git operations trigger the filters, executing the malicious code

The attack requires no direct system access—only the ability to influence what an AI assistant reads (a malicious README, a poisoned GitHub issue, a compromised webpage).

The Deployment Fragmentation Problem

Here’s what makes patching MCP servers harder than traditional software: nobody deploys them the same way.

Package managers, containers, ephemeral runners, manual git clones. Five different installation methods with five different update procedures. No centralised deployment pipeline. No automated update mechanism that works across all of them.

When a CVE drops, practitioners get version numbers. What they need is deployment-specific remediation steps, verification commands, rollback procedures if something breaks. The fact that the Docker image is still vulnerable months after the pip package was patched shows how easily updates fall through the cracks in this fragmented space.

Verification Checklist

After applying remediation, verify your deployment:

Note on version checking: mcp-server-git does not support a --version flag. Version verification depends on your installation method and requires checking the Python package metadata.

1. Check installed version:

# For uvx (mcp-server-git doesn't offer a --version flag)
# Best to force it to refer to the latest available version
uvx mcp-server-git@latest

# For uv tool install
uv tool list | grep mcp-server-git

# For pip / uv pip
pip list | grep mcp-server-git

# For Docker (if you built your own image)
docker run --rm --entrypoint pip mcp-git-patched:latest show mcp-server-git


Expected output: Version 2025.12.18 or later (current latest: 2026.1.14)

2. Verify configuration scope:

Ensure your MCP configuration uses the --repository flag to limit operations to specific directories:

{
 "mcpServers": {
   "git": {
     "command": "uvx",
     "args": [
       "mcp-server-git",
       "--repository", "/path/to/workspace"
     ]
   }
 }
}


3. Review cross-MCP-server attack surface:

If you’re running both Git and Filesystem MCP servers, understand that they can interact in ways that compound risk. Consider:

• Can the Filesystem MCP write to git repository directories?
• Are git hooks or filter configurations accessible to file write operations?
• What’s the effective permission scope of the combined system?

4. Monitor for unusual tool invocations:

If your MCP platform provides logging, watch for:

• Tool calls with arguments starting with - (should now fail)
• Path traversal patterns (../, absolute paths outside scope)
• Attempts to initialise repositories in unexpected locations (should fail - tool is removed)

Deployment Recommendations

After working through all these deployment methods, here’s what makes sense:

Use uvx instead of Docker for reference implementations unless you have a specific reason to containerise. It’s simpler to configure and there’s no image lag. The tradeoff: uvx caches versions, so you need to actively manage updates. You have options:

• Periodic manual updates (probably my preferred option): Run uv cache clean mcp-server-git when you want to update, then let it cache the new version.
• Always check for updates: Add the -upgrade flag to your MCP config:
• "args": ["--upgrade", "mcp-server-git", "--repository", "/path"]

• This checks PyPI on every run and upgrades if a newer version exists, at the cost of a slower execution
• Pin to specific version: Use mcp-server-git==2026.1.14 in your config if you want stability and will update manually when needed.

Docker’s advantage is isolation, but until the official image is updated regularly, you’re building your own anyway.

If you pin versions for production stability (which is reasonable), set up monitoring for security advisories. The tradeoff between “always latest” and “pinned for reproducibility” is real, but you can’t just pin and forget.

Treat MCP server permissions like you’d treat database credentials or API keys. What can this server read? What can it write? What can the combined system of multiple MCP servers achieve when they interact? That last question is where things get dangerous.

Test security updates before deploying to production. Even security patches can break things. I know the urgency feels high when a CVE drops, but broken functionality in production is also a problem.

Check whether your actual deployment still matches what’s documented. In this case, following the Docker documentation left users vulnerable because nobody updated the image. That kind of drift happens more than people admit.

Additional Resources

CVE References:

• CVE-2025-68145: https://nvd.nist.gov/vuln/detail/CVE-2025-68145
• CVE-2025-68144: https://nvd.nist.gov/vuln/detail/CVE-2025-68144
• CVE-2025-68143: https://nvd.nist.gov/vuln/detail/CVE-2025-68143

Package Resources:

• mcp-server-git on PyPI: https://pypi.org/project/mcp-server-git/
• Official MCP servers repository: https://github.com/modelcontextprotocol/servers
• Docker Hub (mcp/git): https://hub.docker.com/r/mcp/git

uv Documentation:

• uv cache management: https://docs.astral.sh/uv/concepts/cache/
• uv tools guide: https://docs.astral.sh/uv/guides/tools/
• uvx tools guide: https://docs.astral.sh/uv/concepts/tools/#tool-environments

Last updated: January 23, 2026 | mcp-server-git version: 2026.1.14

‍