Topic starter
11/08/2026 3:19 pm
TL;DR: SSRF and token passthrough remain recurring failure modes in Model Context Protocol servers, with recent disclosures showing how unvalidated destinations, unauthenticated access, and audience-less token forwarding can expose local files, cloud credentials, and internal services, according to Bishop Fox. The issue is not novelty in the attack class but the reintroduction of old trust assumptions into agent-facing infrastructure where request boundaries are now far easier to cross.
Editorial analysis by NHI Mgmt Group, based on content published by Bishop Fox: “Otto Support - SSRF and Token Passthrough with MCP”.
Key questions
Q: What breaks when localhost redirect URIs are used for MCP clients?
A: Localhost flows can still be intercepted if another process can claim the callback path or reuse the expected port pattern.
Q: Why does token passthrough create so much risk in MCP integrations?
A: Because it erases the audience boundary that keeps one credential from being reusable everywhere.
Q: How should security teams handle SSRF risk in MCP servers?
A: Treat SSRF in MCP as an outbound identity control problem, not only an input validation problem.
Practitioner guidance
- Enforce destination allowlists Resolve targets after DNS, check the resulting IPs against private and reserved ranges, and reject requests that resolve to internal or localhost addresses.
- Remove token passthrough by default Give MCP servers their own service credentials or exchange caller tokens for scoped downstream tokens instead of forwarding the original credential.
- Isolate retrieval tools from internal network reach Run fetch-capable MCP services in network segments or containers that cannot reach metadata services, admin panels, or other internal endpoints.
Bottom line: MCP SSRF and token passthrough show how ordinary integration features can become privilege transfer points when trust checks are missing.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/08/2026 3:31 pm
SSRF in MCP is a trust-boundary failure, not a novel exploit class. The underlying flaw is the assumption that a server can safely fetch whatever URL a caller supplies. In MCP, that assumption collapses because the server itself often sits closer to internal services and credentials than the caller ever should. The practitioner conclusion is that destination trust must be treated as a security decision, not a convenience feature.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When should teams allow credential forwarding from an MCP server?
A: Only when the receiving service explicitly expects and validates that exact token format and the integration has been narrowly approved. In most cases, forwarding should be avoided because it breaks audience boundaries and creates unnecessary trust coupling between services. The default posture should be token exchange or server-owned authentication, not passthrough.
👉 Read our full editorial: MCP SSRF and token passthrough expose hidden trust boundary failures