MCP Security March 15, 2026 · 4 min read

MCP Git Server Closes Argument Injection Gaps

A targeted security fix adds consistent defense-in-depth guards to four git server functions that lacked input validation for leading dashes, closing potential command injection vectors.

About the Author

Elliot (@ElliotJLT) identified and fixed this security gap in the MCP git server. The PR was generated with Claude Code, demonstrating how AI assistants can contribute to security hardening.

The Vulnerability

The MCP git server wraps git commands via GitPython, exposing them as tools to AI agents. Two functions — git_diff and git_checkout — already rejected user inputs starting with - to prevent flag injection attacks. But four other functions lacked the same protection:

git_show
git_create_branch
git_log (timestamp parameters)
git_branch (contains/not_contains parameters)

⚠️ Attack Vector

An attacker with filesystem write access (e.g., via mcp-filesystem server) could create malicious git refs like --format=evil under .git/refs/heads/. Without the leading-dash check, these values would be passed as flags to git commands, potentially enabling arbitrary code execution or data exfiltration.

What Changed

The fix adds consistent validation guards matching the existing pattern:

def git_show(repo_path: str, revision: str) -> str:
    # Guard against flag injection
    if revision.startswith("-"):
        raise ValueError("Revision cannot start with '-'")
    
    repo = git.Repo(repo_path)
    return repo.git.show(revision)

Each guarded parameter now rejects inputs starting with -, preventing user-controlled values from being interpreted as command flags.

Functions Hardened

Function	Parameter	Risk
`git_show`	`revision`	Format string injection via `--format`
`git_create_branch`	`branch_name`	Flag injection via branch names
`git_log`	`since`, `until`	Flag injection via timestamp parameters
`git_branch`	`contains`, `not_contains`	Flag injection via filter parameters

Why This Matters

MCP servers often run with significant system access. When an AI agent uses the git server alongside a filesystem server, the combination creates a trust boundary issue: the agent might read a malicious ref name from the filesystem and pass it to a git function without sanitization.

The existing guards on git_diff and git_checkout (plus tests for malicious refs) showed this threat model was already recognized — this PR simply closed the remaining gaps with consistent defense-in-depth.

Defense-in-Depth Principles

This fix exemplifies good security hygiene:

Consistency: All functions handling user input now apply the same validation
Fail-safe defaults: Rejection via ValueError ensures malicious inputs can't slip through
Test coverage: 6 new tests verify rejection of flag-like inputs, including a test that verifies git_show rejects malicious refs even when they exist on disk

Implications for MCP Server Authors

If you're building MCP servers that shell out to command-line tools:

Audit all user-controlled inputs: Any parameter that reaches a CLI should be validated
Block leading dashes: Prevent flag injection by rejecting inputs starting with - or --
Use positional argument separators: Many tools support -- to separate flags from positional args
Consider allowlists: For constrained inputs, validate against known-good patterns

Source: PR #3545 · 79 additions across 2 files · Generated with Claude Code