Saltar al contenido
Fali Fuentes

Two critical flaws in MCP servers expose repositories and bypass SSRF

Leer este artículo en español

On November 8, 2026, two security advisories were published in the official modelcontextprotocol/servers repository affecting the tooling layer of the Model Context Protocol (MCP). Both flaws were reported by ShieldPi and are under review by the maintainers, who confirm partial technical validity. No official patch exists at the time of writing; defense relies on network, filesystem, and least-privilege deployment controls.

Context: MCP and the exposed tooling layer

MCP defines a standardized protocol for LLM agents to invoke local or remote tools such as filesystem, Git, HTTP, or databases. The reference servers mcp-server-git and mcp-server-fetch implement these capabilities and run with the privileges of the process that launches them. Any failure in their input validation breaks the trust model ‘the agent only sees what the server allows’ and opens lateral movement or exfiltration vectors.

The attack surface grows when multiple agents share MCP servers without segmentation by scope or identity. A Git confinement escape or an SSRF bypass in fetch allows a malicious agent—or an injected prompt—to reach resources outside its scope: private repositories, cloud metadata, internal services. The severity lies not in the MCP protocol but in the implementation of its reference servers.

Both advisories were published as GitHub Security Advisories on the same day, indicating coordinated responsible disclosure. The maintainers (PederHP) acknowledge that ‘some technical claims appear valid’ and warn that additional automated submissions will result in blocking. That response suggests patches in days, not weeks, but until then exposure is real in any deployment running versions 2026.11.4 or 2026.10.24.

CVE-2026-41902: confinement escape in mcp-server-git

The validate_opened_repo function verifies the worktree, git dir, and common dir, but omits .git/objects, objects/info/alternates, and symlinks in objects/. A crafted repository inside the allowed root that points its alternates to an external object database—or has objects/ as a symlink to an outside pool—allows git_show to return foreign commits and blobs, and git_checkout/git_create_branch to materialize external history in the authorized worktree.

The confirmed reproduction describes creating two repositories (allowed/crafted and outside), writing the external object path into crafted/.git/objects/info/alternates, and invoking git_show against the server started with –repository allowed. The negative control (sibling repo without alternates) correctly fails, isolating the cause in the incomplete validation of alternates.

The impact spans cross-disclosure of secrets, proprietary code, and history, as well as write priming of the authorized worktree from an external store. The proposed fix requires resolving .git/objects and each alternates target after opening the repo, demanding they remain under the authorized root or rejecting alternates outright, and revalidating in every tool that resolves objects. See the full advisory at GitHub Security Advisory #5487.

CVE-2026-41904: SSRF bypass in mcp-server-fetch

The _is_public_address guard unwraps well-known IPv4-mapped and NAT64 forms but omits the fec0::/10 range (deprecated IPv6 site-local) and trusts ip.is_global, which returns True for fec0::1. Result: the SSRF allowlist accepts requests to non-public destinations. The proof of concept reproduces on versions 2026.11.4 and 2026.10.24; the 36-case matrix correctly rejects loopback, RFC1918, link-local, 307/308 redirects, userinfo, trailing-dot, uppercase-host, 0.0.0.0, and [::].

The reachability note clarifies that on modern kernels fec0::1 typically times out; the translated form [::ffff:0:127.0.0.1] is normalized and correctly blocked. This is a correctness flaw in the guard’s classifier (its threat model includes non-public destinations), not a proven exploit against metadata services on default hosts. The proposed fix explicitly blocks fec0::/10 and ::ffff:0:0/96, and applies deny-by-default over not ip.is_global plus reserved/site-local range checks.

The affected surface is any mcp-server-fetch deployment that resolves URLs controlled by the user or agent. The vector allows pivoting to internal networks if services are listening on site-local. Technical details and test matrix at GitHub Security Advisory #5492.

Immediate mitigations and limits

For mcp-server-git: mount the served repository on a read-only filesystem for the server process; use –repository pointing to a bare copy without alternates or symlinks in objects/; run with a dedicated user without read access outside the root. Requires deployment control (Docker, systemd, K8s). Does not protect if the attacker writes to the served repo via another MCP tool with write capability.

For mcp-server-fetch: deny outbound traffic to fec0::/10 and ::ffff:0:0/96 at the firewall/host (iptables/nftables, cloud security groups); enforce deny-by-default on egress with an allow-list of required domains. Does not fix the logical bug; an attacker who controls DNS or uses a valid IPv4-mapped address could pivot if other flaws exist. Restrict scheme to https:// and allowed domains if the server exposes that configuration.

Cross-cutting measures: exact inventory and versioning of each MCP server per environment; principle of least privilege (dedicated container/user, read-only FS except explicit directories, minimal egress); logging of invocations (git_show, git_checkout, fetch) with parameters and requester; alerts on anomalous patterns (private IPs, ../, alternates); image integrity verification (cosign/sigstore, SBOM) and review of fix PR provenance; subscription to the repo’s GitHub Security Advisories and CVE/NVD.

Next steps and defensive architecture

Today: identify all deployments of mcp-server-git and mcp-server-fetch (versions 2026.11.4 or 2026.10.24) and apply temporary network and FS mitigations. Within 24-48 h: implement egress deny-by-default rules and domain allow-list for fetch; mount served Git repos read-only without alternates. Once the patch is released: deploy the fixed version (expected in days), validate in staging that it resolves the described PoCs.

Review MCP architecture: assess whether the “server per capability” model (Git, fetch, FS, SQL) is properly segmented and whether each agent has its own server scope (zero-trust between agents). The tooling layer is the most exposed surface when autonomous agents invoke tools; segmentation by identity and purpose reduces the blast radius of any individual flaw.

These flaws are not vulnerabilities in the MCP protocol, but in reference implementations. The prompt publication in GitHub Security Advisories and the maintainers’ response indicate imminent official patches; until then, network, filesystem, and least-privilege deployment controls are the only verified defense. Maintaining visibility into advisories and the supply chain will close the loop when the fixes arrive.

Structured reference for readers and AI agents

{
  "format": "rafael-fuentes-article/1.0",
  "language": "en",
  "title": "Two critical flaws in MCP servers expose repositories and bypass SSRF",
  "summary": "Technical analysis of CVE-2026-41902 and CVE-2026-41904: confinement escape in mcp-server-git and SSRF bypass in mcp-server-fetch. Immediate mitigations without official patch.",
  "author": "Rafael Fuentes",
  "publicationDate": "2026-11-09T06:01:35.033+01:00",
  "eventDate": "2026-11-08",
  "url": "https://falifuentes.com/rafael-fuentes-2026-11-09-am-en/",
  "translation": {
    "language": "es",
    "url": "https://falifuentes.com/rafael-fuentes-2026-11-09-am-es/"
  },
  "topics": [
    "AI",
    "Artificial Intelligence",
    "Cloud Security",
    "Cybersecurity",
    "Cybersecurity News",
    "English",
    "Supply Chain"
  ],
  "sources": [
    "https://github.com/modelcontextprotocol/servers/issues/5487",
    "https://github.com/modelcontextprotocol/servers/issues/5492"
  ]
}
SYSTEM_EXPERT
Rafael Fuentes – BIO

I am a seasoned cybersecurity expert with over twenty years of experience leading strategic projects in the industry. Throughout my career, I have specialized in comprehensive cybersecurity risk management, advanced data protection, and effective incident response. I hold a certification in Industrial Cybersecurity, which has provided me with deep expertise in compliance with critical cybersecurity regulations and standards. My experience includes the implementation of robust security policies tailored to the specific needs of each organization, ensuring a secure and resilient digital environment.

Share
Scroll al inicio