Analysis · By Sam Ortega (pen name) · 11 October 2026

MCP SSRF: What October 2026's Disclosures Teach About Agent Egress

In the first days of October 2026, several separate lines of security research converged on an old bug class: server-side request forgery (SSRF). This time the dangerous URL is not typed into a web form by an attacker. It is chosen by an AI agent, often after the agent has read content the attacker controls.

This is an analysis piece. It summarizes what the primary sources say, separates confirmed facts from open questions, and ends with a practical checklist for teams running MCP servers, MCP clients and agent runtimes. For the wider context, see our agentic AI security landscape for October 2026.

What happened

1. The reference MCP fetch server gets a default SSRF guard

The CVE record for CVE-2026-104120, last updated on 6 October 2026, describes server-side request forgery in the fetch_url function of mcp-server-fetch and mcp-server-everything up to version 2026.6.4. It is classed as CWE-918 and scored 7.3 (High) under CVSS 3.1 and 6.9 (Medium) under CVSS 4.0. The record states that an exploit has been disclosed publicly.

On 5 October 2026, maintainers merged pull request #5033 into the repository's v2/main line, closing issue #4838. It was ported, with credit, from an earlier community pull request (#4890) opened on 28 September. According to the pull request description:

A request hook now resolves the host before every request the server sends, including the robots.txt check, the page fetch and every redirect hop, and refuses the request if any resolved address is not publicly routable.
The refused set includes loopback, RFC 1918 private ranges, the link-local range 169.254.0.0/16 used by major cloud metadata services, and other IANA special-purpose ranges.
A new --allow-private-ips flag restores the old behavior for local development. The maintainers chose a command-line flag partly because it is host-side configuration, "so the model calling the tool cannot turn it off".
Two limits are documented: a DNS rebinding window remains between the check and the connection, and names the server cannot resolve are passed through.

We could not confirm a published package release containing the fix at the time of writing. Check the changelog of the version you run rather than assuming you are protected.

2. One researcher, the same bug in many organizations

Independent researcher Syed Anas Mohiuddin describes finding the same SSRF-shaped assumption in MCP servers from Google, Anthropic, Microsoft and Weaviate over the first nine months of 2026. The best-documented case is Google's MCP Toolbox for Databases. Its CVE record, CVE-2026-14540, says the generic HTTP source in versions 0.3.0 through 1.4.0 created its HTTP client "without a restrictive CheckRedirect policy hook" and without target IP validation, scored 8.0 (High) under CVSS 4.0. The fix is googleapis/mcp-toolbox pull request #3448, which the researcher says shipped in v1.5.0.

His write-up also makes a point every MCP developer should note. The reference fetch server contained a safeguard function, check_may_autonomously_fetch_url(), but according to the researcher the prompt handler called the fetch function directly and never invoked it. A guard that exists on one code path but not another is not a guard.

On 6 October, The Next Web reported on an update in which the researcher says Google, JPMorgan Chase, Weaviate, France's interministerial digital directorate (DINUM) and the city government of Tangerang in Indonesia each fixed SSRF issues he reported, while five MCP servers under the US General Services Administration's Technology Transformation Services were still in triage. Those status claims come from the researcher and have not been independently confirmed by us.

3. The client side: OAuth discovery as an SSRF channel

SSRF is not only a server problem. GitHub advisory GHSA-c9xm-49cp-xcr9, published on 29 June 2026 for rmcp, the Rust MCP SDK, describes an OAuth client that accepted a server-controlled resource_metadata URL from a WWW-Authenticate header and fetched it without same-origin or private-network validation. A malicious MCP server could therefore make the client send a request to localhost, private ranges or a cloud metadata endpoint from the victim's network. The advisory lists versions up to 1.8.0 as affected and 2.0.0 as patched.

The MCP project's Security Best Practices page (draft specification) now has a dedicated SSRF section covering exactly this flow. It recommends requiring HTTPS for OAuth-related URLs, blocking private and link-local ranges, validating every redirect target, using egress proxies, and being aware of DNS time-of-check to time-of-use gaps. It also warns: "Avoid implementing IP validation manually."

4. The runtime: AgentCorruption on Amazon Bedrock AgentCore

On 8 October, Zenity Labs disclosed AgentCorruption at SecTor 2026 in Toronto. In its technical write-up, Zenity says a prompt to a test agent equipped with an outbound HTTP tool made the agent request the instance metadata endpoint at 169.254.169.254 and relay temporary credentials for its execution role, which the researchers then used from outside AgentCore. Zenity says the default execution role's permissions extended to other agents in the same AWS account and region, and that it reproduced the metadata access through other tools, including a shell tool.

According to Zenity's timeline, it reported the metadata issue on 25 December 2025. AWS told Zenity that since 14 February 2026 newly deployed AgentCore agents use IMDSv2 only. Zenity's press release adds that its testing confirmed AWS had reduced the default execution role's permissions, including removing those that let agents invoke other agents, read private conversations or access secrets in AWS Secrets Manager. AWS disputes the framing. Its statement, published in Zenity's post, says "The behavior described is documented and expected" and recommends "that customers grant their execution roles only the permissions their agents need."

AgentCorruption is not an MCP bug, but it has the same shape: a model-chosen request reaches an internal endpoint, and the agent's identity decides how bad the outcome is.

Why SSRF is different when an agent holds the URL

In a classic web application, the attacker submits the URL. In an agent system, anyone who can place text where the model will read it, such as a web page, a document, a ticket or another tool's output, may be able to steer the URL. That is indirect prompt injection, which OWASP describes in LLM01:2025. Three practical consequences follow.

Every URL, path or endpoint parameter is attacker-influenced. The model is not a trusted caller. Validation has to happen in code or at the network layer, not in the system prompt.
Open-ended tools carry the most risk. OWASP's LLM06:2025 Excessive Agency guidance explicitly recommends avoiding open-ended extensions such as "fetch a URL" where a narrower tool will do.
Identity sets the blast radius. The same request is a nuisance from a workload with no credentials and an incident from a workload whose metadata service hands out a broad role.

In the OWASP Top 10 for Agentic Applications, this maps mainly to ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse, typically triggered by ASI01 Agent Goal Hijack. Vulnerable third-party MCP servers also fall under ASI04 Agentic Supply Chain Vulnerabilities.

A defensive checklist for MCP and agent egress

Inventory every place model output becomes a network request. Fetch and browser tools, HTTP sources in database toolboxes, configurable API endpoints in plugins, and OAuth discovery in MCP clients all count.
Enforce egress at the network layer. Run agents and MCP servers behind an egress proxy or network policy that denies private, loopback and link-local destinations by default. The MCP specification points to egress proxies such as Smokescreen. In-code checks still have gaps, as the fetch server's own documented DNS rebinding limit shows.
If you validate in code, validate resolved addresses on every hop. Check after DNS resolution, re-check every redirect, and handle IPv4-mapped IPv6 and unusual encodings. Prefer maintained libraries over hand-written parsers, as the MCP specification advises. The OWASP SSRF Prevention Cheat Sheet is a good baseline.
Guard every code path. Tools, prompts, resources and completions must route through the same check.
Keep safety switches on the host. Opt-outs such as --allow-private-ips belong in server configuration that the model cannot change.
Harden metadata services. On AWS, require IMDSv2, which needs a session token obtained with a PUT request. In our assessment this is not sufficient on its own for agents whose tools can send arbitrary methods and headers or run shell commands, so also block metadata addresses at the network layer where the platform allows.
Apply least privilege to agent identities. Give each agent its own narrowly scoped role, keep public-facing and internal agents apart, and prefer short-lived credentials. AWS's AgentCore runtime security best practices are the starting point for that platform.
Prefer narrow tools. A tool that fetches from a fixed allowlist of domains is far easier to secure than a general fetcher. Avoid exposing generic HTTP or shell tools to internet-facing agents.
Patch and pin. Track CVE-2026-104120, CVE-2026-14540 and GHSA-c9xm-49cp-xcr9. Pin MCP server versions and review changes before upgrading, as you would for any dependency.
Log and alert. Requests from agent workloads to private ranges or metadata endpoints are rarely legitimate. Make them visible and add human-in-the-loop approval for high-impact actions.

What we do not know yet

Whether a published release of mcp-server-fetch already includes the guard merged on 5 October.
Whether agents deployed on AgentCore before 14 February 2026 have moved to IMDSv2. Public sources we reviewed do not say.
The final status of the MCP servers the researcher says are still in triage.

We will update this analysis when maintainers or vendors publish more detail.

Frequently asked questions

What is SSRF in an MCP server?

Server-side request forgery (SSRF) happens when a server can be induced to send requests to destinations the operator never intended, such as localhost services, private network addresses or cloud metadata endpoints. In an MCP server, the URL or path usually comes from the AI model, so anyone who can influence what the model reads may be able to influence where the server connects.

Is the official MCP fetch server safe to use now?

A default guard against private, loopback and metadata addresses was merged into the v2/main line of the modelcontextprotocol/servers repository on 5 October 2026 (pull request #5033). Check that the release you run includes it, and note the limits the maintainers documented: DNS rebinding is not fully closed and names the server cannot resolve are passed through. Network-level egress controls are still recommended.

Does IMDSv2 stop AI agents from stealing cloud credentials?

IMDSv2 raises the bar because a caller must first obtain a session token with a PUT request. It is not a complete answer for agents whose tools can send arbitrary HTTP methods and headers or run shell commands. Pair it with network blocks on metadata addresses and narrowly scoped execution roles.

How is MCP SSRF related to prompt injection?

Prompt injection, especially indirect prompt injection through web pages, documents or tool output, is often how an attacker chooses the URL. SSRF is what turns that manipulation into network access the attacker could not otherwise reach.

Which OWASP Agentic Top 10 risks does this map to?

Mainly ASI02 Tool Misuse and Exploitation and ASI03 Identity and Privilege Abuse, often triggered by ASI01 Agent Goal Hijack. Vulnerable third-party MCP servers also fall under ASI04 Agentic Supply Chain Vulnerabilities.

Sources

This article is analysis. Bylines on AIAgentThreats are disclosed pen names of our editorial team. Spotted an error? Email info@aiagentthreats.com. See our Editorial Standards.