Notifications
Clear all
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.
NHIMG editorial — based on content published by Bishop Fox: SSRF and Token Passthrough in MCP Servers
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
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.
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: What breaks when MCP servers can reach internal services directly?
A: A single untrusted tool call can become a pivot into cloud metadata, localhost services, or internal admin planes.
Practitioner guidance
- Validate outbound destinations after resolution Resolve the target, check the final IP against private and reserved ranges, and repeat the check after each redirect hop.
- Replace token passthrough with scoped token exchange Use server-held service credentials or an RFC 8693 style exchange path when downstream authentication is required.
- Segment MCP services away from internal reach Run MCP servers in network namespaces, containers, or other isolated segments that cannot route to sensitive internal services.
What's in the full article
Bishop Fox's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step breakdown of the mcp-atlassian CVE chain and how SSRF was chained into remote code execution
- Specific destination validation logic, including post-DNS and post-redirect checks for private and reserved ranges
- Practical mitigation patterns for token passthrough, including scoped token exchange and allowlist design
- Concrete case-study context for MarkItDown and OpenClaw that implementation teams can use in testing
👉 Read Bishop Fox's analysis of SSRF and token passthrough in MCP servers →
MCP SSRF and token passthrough: are your controls actually holding?
Explore further
11/08/2026 3:31 pm
MCP SSRF is really a destination-governance failure, not just a web bug. The problem is that MCP servers are allowed to decide where requests go on behalf of callers, often across internal and external boundaries. That makes destination validation a governance control, not a coding nicety. The practical conclusion is that any MCP deployment without explicit outbound trust boundaries is already operating with an identity exposure path.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable if an MCP server accepts the wrong audience token?
A: Accountability sits with both the authorization server operator and the MCP server operator. The issuer must bind tokens to the correct resource URI, and the resource server must reject mismatched tokens. If either side skips that control, the boundary fails and the resulting access is not defensible.
👉 Read our full editorial: MCP SSRF and token passthrough expose hidden trust boundary failures
