← Articles

MCP Security Fixes: Git Argument Injection and Robots.txt Edge Cases

MCP Security Hardening March 13, 2026 · Elliot (ElliotJLT) · Git fix · Fetch fix

The Author

Elliot (GitHub: ElliotJLT) submitted both security fixes on the same day, demonstrating the kind of security-focused review that production MCP deployments need. The coordinated submission suggests systematic audit of the reference server implementations.

Why This Matters

As MCP servers move from development toys to production infrastructure, security edge cases become critical. Today's fixes address two distinct vulnerability classes:

Git argument injection — where maliciously crafted inputs could escape argument boundaries
Robots.txt 5xx handling — where server errors could be misinterpreted as permission to fetch

Security context: MCP servers often run with elevated permissions to access local files, execute commands, or fetch remote content. Input validation gaps can escalate to arbitrary command execution or data exfiltration.

Git Argument Injection Guards

PR #3545 adds missing argument injection guards to the git MCP server. The vulnerability class is well-known: git commands that accept user input can be exploited if that input starts with - (interpreted as a flag) or contains shell metacharacters.

For example, a branch name like --upload-pack=malicious-script passed to git clone could execute arbitrary code. The fix adds the standard -- argument separator and input validation:

// Before: vulnerable to argument injection
git checkout ${branchName}

// After: protected with argument separator
git checkout -- ${sanitizedBranchName}

This pattern needs to be applied consistently across all git operations that accept user-provided inputs: branch names, file paths, commit references, and remote URLs.

Robots.txt 5xx Handling

PR #3547 addresses an edge case in the fetch MCP server: what happens when robots.txt returns a 5xx server error?

The previous behavior likely treated this as "no robots.txt exists" (permissive), when the correct interpretation is "server is having problems, assume restrictive." This matters for:

Rate limiting: A server returning 503 might be overloaded — autonomous fetching should back off
Security: A firewall or WAF returning 5xx shouldn't be interpreted as "go ahead and crawl"
Legal compliance: Respect for robots.txt is often a legal expectation; ambiguous cases should fail closed

The fix blocks autonomous fetching when robots.txt returns 5xx, requiring explicit user confirmation to proceed.

The Broader Pattern

These fixes illustrate the security maturation curve for MCP:

Phase 1: Get it working (feature development)
Phase 2: Make it reliable (error handling, edge cases)
Phase 3: Make it secure (input validation, fail-closed defaults)

The MCP reference servers are now firmly in Phase 3. Expect continued security hardening as the ecosystem matures and more security researchers examine the codebase.

Implications for MCP Operators

If you're running MCP servers in production:

Update promptly: These fixes should be pulled into your deployments
Audit custom servers: If you've written custom MCP servers, apply the same patterns
Defense in depth: Run MCP servers with minimal permissions, even with these fixes in place

The security surface of AI tool-use infrastructure is still being mapped. Today's fixes won't be the last.