MCP servers keep trusting the wrong URLs: what recent advisories show

Two MCP server advisories published in the first week of October 2026, one from Splunk and one from AWS, describe different bugs with the same root cause: a tool took a value that someone else could influence and used it to decide where a request goes or what a command does. Read alongside earlier fixes in Google's MCP Toolbox and the official Rust MCP SDK, they show a pattern that engineering and security teams should plan for, not treat as a run of bad luck.

What was disclosed

Splunk MCP Server: a custom tool that sends the caller's token elsewhere

On 7 October 2026 Splunk published SVD-2026-1004 for its MCP Server app, fixed in version 1.2.1. In versions below 1.2.1, a user with the mcp_tool_admin capability could configure a custom API tool to send requests to a URL they control. When another user with the mcp_tool_execute capability ran that tool, the server could send the runner's Splunk authentication token to that URL. Splunk's advisory says the person controlling the URL "could capture the token and use it to access data and perform actions as the user who ran the tool."

Splunk rates it medium (CVSS 3.1 score 5.3), because exploitation needs a privileged tool author and a second user to run the tool. That rating is fair for the product, but the shape of the bug matters more than the score: a tool definition written by one person ran with another person's credentials, and nothing checked where those credentials were going.

AWS Security Agent MCP server: a revision that became an option

On 1 October 2026 AWS Labs published GHSA-8g28-rj54-p5p2 for awslabs.security-agent-mcp-server, affecting versions 0.1.1 up to (but not including) 0.2.0. Its diff scan passed a revision reference into a git command in a way that let a crafted value be read as a command-line option. The advisory says someone who can influence that value, "for example by controlling content in a scanned repository", can create, overwrite or truncate files anywhere the server process can write, including shell start-up files and SSH authorized_keys files. It is rated high (8.2).

Two details stand out. First, the attacker doesn't need to talk to the server at all: content in the repository being scanned is enough. Second, the advisory notes that the operation reports that no diff was found, so the write leaves no signal for the operator. The only workaround offered before upgrading is to scan trusted repositories only and to run the server as a least-privileged user in an isolated environment.

Earlier fixes with the same shape

These are not isolated. In June, Google merged an SSRF guard into MCP Toolbox for Databases. The pull request describes remediating "a high-severity SSRF vulnerability (CWE-918) in the HTTP source implementation", and adds protection against DNS rebinding plus settings for allowed and blocked IP ranges and private networks.

The official Rust SDK for MCP had a client-side version of the problem. Its advisory GHSA-c9xm-49cp-xcr9 explains that the rmcp OAuth client accepted a resource_metadata URL from a server's WWW-Authenticate header and fetched it with no same-origin or private-network check. A malicious MCP server could point that URL at localhost, a private network address or a cloud metadata endpoint, and the client would make the request from inside the victim's network. The fix is in rmcp 2.0.0.

Analysis: why MCP makes this bug class more likely

Server-side request forgery and argument injection are old problems. What MCP changes is who supplies the input.

• The caller is a model, steered by content. An MCP tool's arguments are written by an AI agent, and the agent is steered by whatever it reads: issues, documents, web pages, repository files. Any of those can carry instructions. The AWS advisory makes this concrete: repository content was enough to reach the vulnerable argument. Treat every tool argument as untrusted, even when the tool is only called by your own developers' assistants.
• Tools are written quickly and forked often. Many MCP servers are thin wrappers around an HTTP client or a command-line tool. That makes it easy to forget the checks a mature integration would have, such as a redirect policy or a -- before a user-supplied git argument.
• Credentials sit next to the network. An MCP server usually holds tokens for the service it wraps, and often runs inside a network that can reach internal systems. The Splunk case shows a token leaving with a request; the Rust SDK case shows a client reaching internal addresses it was never meant to call.
• Trust runs in both directions. The Rust SDK advisory is about the client trusting the server. Connecting an AI tool to an MCP server you don't control is itself a risk, separate from what the server's tools do.

What is not new, and what is overstated

None of these advisories describes a flaw in the MCP specification itself. They are implementation bugs, with ordinary fixes: validate destinations, block private ranges by default, refuse redirects you didn't expect, separate options from arguments, and keep credentials scoped to the person and the destination. Severity also varies a lot: Splunk's issue needs two privileged users, while the AWS one can be triggered by a scanned repository. The pattern is useful, but each case still needs its own risk assessment.

What it means for engineering and security leaders

The useful question is not "is MCP safe?" but "do we know which MCP servers our developers' AI tools call, what credentials those servers hold, and what network they can reach?" Most teams can't answer that today, because AI tools let each developer add servers locally in a few lines of configuration.

That leads to three priorities:

1. Inventory. Know which MCP servers are configured on developer computers, which versions, and who added them. You can't patch what you can't see.
2. Central control of credentials and egress. A server that holds a token and can reach the internal network is the asset worth protecting. Running connectors where credentials and network access are controlled centrally, rather than on every laptop, makes a vulnerable server less damaging.
3. A record of every call. The AWS bug produced no signal in the tool's own output. A record of which tool was called, by whom, with what outcome, is what lets you check whether a vulnerable version was ever exercised.

Practical takeaways for this week

• Search developer configurations for security-agent-mcp-server (upgrade to 0.2.0 or later), the Splunk MCP Server app (1.2.1 or later), MCP Toolbox for Databases, and Rust applications that depend on rmcp (2.0.0 or later).
• For any MCP server that fetches URLs, check that it blocks loopback, link-local, private and cloud metadata addresses, and that it re-checks redirect targets.
• For any MCP server that runs a command-line tool, check that user-supplied values can't be read as options.
• Run MCP servers as least-privileged users, with no access to home directories, SSH keys or cloud credentials they don't need.
• Review who can define custom tools in shared MCP servers, and whether those tools run with the caller's credentials.
• Prefer MCP servers you or a vendor maintain over unreviewed forks, and track their security advisories like any other dependency.

Where SpanDock fits

The SpanDock MCP gateway, on the Premium and Enterprise plans, addresses part of this: AI tools on every computer call one MCP server, connector credentials stay on the server and are never sent to computers, every connector starts read-only for everyone, and every call is recorded with the connector and tool, the outcome, and the person and computer. In Enforced mode it also reports, or moves aside, the other MCP servers configured in each AI tool. It doesn't fix a vulnerable connector, so patching still matters. For more, see setting up the MCP gateway.