When MCP Maintainers Say "No Trust Boundary" — Why Local SSRF Is Still Your Problem

Last week, a security researcher reported a CVSS 7.5 SSRF vulnerability in a popular MCP server. The maintainer's response? "This runs locally. There's no trust boundary. Not applicable."

The issue was closed. The vulnerability still exists.

This isn't an isolated incident. It's a pattern — and it reveals a fundamental misunderstanding of how attacks work in the MCP ecosystem.

"Local" Doesn't Mean "Safe"

The argument goes: if both the MCP client and server run on the same machine, there's no untrusted party, so there's no threat model for SSRF.

This is wrong for three reasons:

1. SSRF on localhost is real

Your MCP server doesn't exist in isolation. It runs alongside your local database, internal APIs, cloud metadata endpoints (169.254.169.254 on AWS), and every other service listening on localhost. An SSRF vulnerability in a "local" MCP server lets an attacker hit any of these — from inside your own machine.

SSRF doesn't care about "trust boundaries." It cares about network access. If your process can reach localhost:5432 or http://169.254.169.254/latest/meta-data/, an SSRF payload can too.

2. The client is the attack surface

MCP clients load tool configurations, execute tool calls, and often process untrusted prompts. If a malicious prompt injects a crafted URL that gets passed to an MCP tool — the SSRF fires. The "trusted client" becomes an unwitting relay.

Think about it: your AI assistant processes a user prompt → the LLM generates a tool call with a malicious URL → your MCP server fetches it → your local services are exposed. The attacker never needs to "break in." They just need to send a message.

3. Supply chain compromise is real

MCP extensions, plugins, and configurations are distributed across a fragmented ecosystem. A compromised MCP server package or a malicious tool definition can inject SSRF payloads that execute on your "trusted local" infrastructure.

The Pattern: Dismiss and Hope

When researchers report these vulnerabilities, maintainers frequently respond with one of:

• "We run locally, so no threat" — See above.
• "The user controls the input" — Until they don't. Prompt injection exists.
• "It's the user's responsibility" — Then why do we validate input anywhere?

This pattern isn't unique to one project. It's a systemic issue across the MCP ecosystem. Of 28 MCP-related projects scanned by ccs-verifier, we identified 7 confirmed vulnerabilities including multiple SSRF and RCE instances. Most remain unacknowledged weeks after disclosure.

Runtime Verification Doesn't Care About Your Threat Model

Here's what's missing: most MCP security discussions assume you can reason about trust at design time. You define your threat model, you identify your trust boundaries, and you're done.

But runtime behavior doesn't care about your threat model. It does what it does.

That's why runtime verification matters. Instead of arguing about whether a trust boundary exists, you verify every operation as it happens:

• Is this URL pointing to a metadata service? → Block.
• Is this path traversal trying to escape the sandbox? → Block.
• Is this SQL query parameterized? → If not, block.
• Is this exec call running untrusted code? → Block.

Runtime verification is not about trust assumptions. It's about enforcement. It validates structure, schema, latency, cost, identity, and integrity — on every single call, regardless of who made it or where it's running.

What CCS Does Differently

The CCS (Computational Compliance Specification) defines 6 dimensions of runtime verification for agent systems:

1. Structure — Validate output format and nesting
2. Schema — Enforce type contracts
3. Latency — Detect anomalous delays
4. Cost — Cap resource consumption
5. Identity — Verify caller/callee authenticity
6. Integrity — Confirm execution wasn't tampered with

The reference implementation, ccs-verifier, performs this verification in <10μs P50 latency — fast enough for real-time MCP traffic without degrading performance.

This isn't theoretical. Palo Alto Networks recently referenced the CCS specification (DOI: 10.5281/zenodo.21729995) in their security research, validating the approach at industry scale.

The Bottom Line

Your MCP server runs "locally." Your threat model says "no untrusted input." Your maintainer closed the issue.

Your metadata endpoint doesn't care.

Runtime verification is the difference between hoping you're safe and proving you're safe. The MCP ecosystem needs less threat model debates and more runtime enforcement.

---

This article is based on publicly available vulnerability disclosures and open-source security research. Specific project names are omitted to encourage constructive security discourse.

Comments

[Mads Hansen]

The local-process point is important, but URL validation alone is easy to bypass. A robust SSRF control needs to canonicalize the URL, resolve every address, reject loopback/private/link-local/reserved IPv4 and IPv6 ranges, and repeat that check after every redirect. It also needs tests for DNS rebinding, mixed/encoded IP forms, IPv4-mapped IPv6, credentials in URLs, and proxy environment variables. The stronger default is architectural: give fetch-capable tools an explicit hostname allowlist and run them with network egress that cannot reach metadata, localhost, or internal subnets. Runtime verification can then provide defense in depth and evidence, but it should not be the only barrier between model-generated input and privileged network reachability.