MCP SSRF and token passthrough expose hidden trust boundary failures

At a glance

What this is: This analysis shows how SSRF and token passthrough in MCP servers can turn ordinary content-retrieval and API-calling features into credential exposure, internal access, and even RCE paths.

Why it matters: It matters because identity, token, and destination trust assumptions have to hold across NHI, agentic AI, and human-operated tooling, or a single integration can collapse the boundary between intended and unintended access.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 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.

👉 Read Bishop Fox's analysis of SSRF and token passthrough in MCP servers

Context

Model Context Protocol puts tools and data sources behind a server-side broker, which makes destination handling and token handling part of the identity boundary, not just the transport layer. In this article's primary theme, MCP security, the problem is that a server can be tricked into requesting or forwarding something the caller should never have been able to reach.

SSRF and token passthrough are familiar web flaws, but MCP makes them more dangerous because retrieval and delegation are core functions. When a server can fetch internal URLs, metadata endpoints, or private files, and can also forward caller tokens without audience checks, the identity model collapses from controlled delegation into uncontrolled trust extension. That is why these issues belong in NHI governance, API trust design, and agent-era access control reviews, not only in web application testing.

Key questions

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. Validate destinations after DNS resolution, block private and reserved ranges, and re-check every redirect hop. Then segment the service so a validation miss cannot reach metadata endpoints or internal systems.

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. When an MCP server forwards a caller token without validation, downstream systems may accept access that was never meant for them, and audit trails become ambiguous about who actually authorised the action.

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. Once that happens, the server is no longer just retrieving content. It is acting as a bridge from user input into protected infrastructure, which dramatically increases blast radius.

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.

Technical breakdown

SSRF in MCP servers

Server-side request forgery happens when an MCP tool accepts a destination, the server performs the request, and the response is returned to the caller. Without destination validation after DNS resolution and redirect handling, the server can be driven toward private IPs, localhost services, metadata endpoints, or internal admin interfaces. In MCP, that is especially dangerous because content retrieval tools are expected to reach outward, so the attack blends into normal functionality. The key failure is that network reachability becomes user influence. That turns a utility feature into an internal pivot point.

Practical implication: validate destinations against explicit allowlists after resolution and every redirect hop.

Token passthrough and audience trust

Token passthrough occurs when an MCP server forwards a caller's token to a downstream system without checking that the token was issued for that audience. OAuth audience boundaries exist to stop one credential from being reused everywhere, but passthrough erases that boundary and turns the server into a confused deputy. This creates accountability gaps because downstream access no longer clearly belongs to the original caller or to the MCP server itself. In practice, the risk is not just misuse, but the loss of a reliable trust chain across services.

Practical implication: use server-held credentials or scoped token exchange instead of forwarding caller tokens.

Why MCP compounds old flaws

MCP makes classic flaws harder to contain because tool calls are now embedded in automation and agent workflows rather than isolated application requests. That means one unsafe URL field or one forwarded credential can connect to cloud metadata, local files, or downstream APIs across environments that were never meant to share trust. The architectural issue is not that MCP invents new bugs, but that it turns ordinary server-side behavior into a cross-domain identity bridge. That bridge must be treated as a privileged boundary, not a convenience layer.

Practical implication: segment MCP services so a destination-validation failure cannot reach internal networks or metadata services.

Threat narrative

Attacker objective: The attacker wants to turn an MCP server's trusted outbound reach into credential theft, internal access, or execution on a developer system or cloud account.

1. Entry occurs when an attacker supplies a malicious URL, redirect target, or header value to an MCP tool or middleware layer that trusts caller-controlled destinations.
2. Escalation follows when the server makes an outbound request to internal infrastructure, localhost, or a cloud metadata endpoint and returns data or forwarded credentials.
3. Impact occurs when the attacker uses exfiltrated secrets, misrouted tokens, or writable shell hooks to reach cloud accounts, internal services, or remote code execution.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Token passthrough creates audience confusion that OAuth was designed to prevent. A caller's token is issued for one audience, but passthrough lets a server reuse it elsewhere as if the boundary did not matter. That breaks accountability, auditability, and scope control in one move. The implication for practitioners is that delegated access must be expressed through scoped exchange or server-held credentials, not blanket forwarding.

Old confused-deputy patterns become more dangerous when packaged as agent infrastructure. MCP does not create new trust failures so much as make them easier to repeat at scale across tools, vendors, and workloads. When a server can fetch, forward, and chain actions on behalf of a caller, the blast radius is no longer limited to one application context. Security teams need to treat MCP gateways as privileged identity brokers, not as routine integration plumbing.

Destination validation and token audience validation should be reviewed as a pair. The article's case studies show that SSRF and token passthrough are complementary failure modes, not separate checkboxes. One expands what the server can reach, the other expands what the server can speak as. Practitioners should therefore review outbound routing, credential handling, and token scope together, because fixing only one leaves the same trust boundary exposed.

Named concept: identity reachability debt. MCP environments accumulate identity reachability debt when outbound requests, forwarded tokens, and internal services are allowed to trust each other too easily. The debt appears harmless while integrations are small, then converts into exploitable privilege when a single tool can reach too far. The practical implication is that teams should inventory every place where server-side identity can cross a trust boundary.

From our research:

• 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.
• Forward look: Guide to the Secret Sprawl Challenge shows why sprawl and exposure need to be handled as lifecycle problems, not one-off cleanup tasks.

What this signals

Identity reachability debt: MCP deployments accumulate risk whenever a server can both choose destinations and move credentials across boundaries. That debt is invisible until one integration reaches a private network, a metadata service, or an internal API that should never have been in scope. Security teams should map every outbound trust edge before agent workflows multiply it.

The governance signal is straightforward. If an MCP server can reach private services or forward caller credentials, it already sits inside the trust boundary that most teams assume is external. That means architecture reviews, not just code review, need to cover outbound routing, token exchange, and internal segmentation together.

The practical next step is to align MCP controls with zero trust assumptions and the access scope discipline used for NHI. When a tool can fetch data and speak with delegated authority, the control question becomes whether that authority is still bounded at the point of use, not merely at provisioning time.

For practitioners

• 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. If the request can land on localhost, a metadata endpoint, or an internal admin network, the MCP tool is too permissive.
• Replace token passthrough with scoped token exchange Use server-held service credentials or an RFC 8693 style exchange path when downstream authentication is required. Only forward caller tokens to explicitly allowlisted services that expect and validate that token format.
• 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. That way, even if destination validation fails, the SSRF path has no useful target.
• Review token audience boundaries in every integration Check whether the receiving API actually validates audience claims and whether the MCP server is acting as a proxy, broker, or deputy. Any integration that relies on trust by forwarding should be treated as a design defect until proven otherwise.
• Test chained failure paths, not single controls Exercise the full path from URL input to downstream request to credential reuse to file or account impact. MCP incidents often emerge only when two ordinary flaws combine, so the test plan has to cover that chain explicitly.

Key takeaways

• SSRF and token passthrough are old failure modes, but MCP turns them into identity boundary problems with much larger blast radius.
• The case studies show how unvalidated destinations, audience-less token forwarding, and weak network segmentation can combine into internal access, credential theft, or RCE.
• Practitioners should treat outbound trust, token audience, and service segmentation as one control surface, not three separate hygiene tasks.

Key terms

• Server-Side Request Forgery: An attack pattern where a vulnerable server is tricked into making requests on the attacker’s behalf. In application exploitation, SSRF can be used to reach internal resources, fetch malicious payloads, or amplify a flaw into full code execution.
• Token Passthrough: Token passthrough is the practice of forwarding an authentication token through intermediaries instead of validating it at each trust boundary. In MCP this is prohibited because it prevents the server from proving who is actually authorised to act. The result is weaker accountability and a larger attack surface for stolen or replayed credentials.
• Audience Validation: Audience validation checks that a token was issued for the exact service receiving it. In MCP, this prevents a valid token for one server from being reused elsewhere, which is critical because agent-driven workflows often move across multiple tools and trust domains.
• Identity reachability debt: The accumulation of hidden access routes that keep privilege alive even after a partial cleanup. It is a governance problem, not a technical glitch, because the entitlement graph still contains routes to the sensitive role.

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

👉 Bishop Fox's full post covers the case studies, exploit paths, and mitigation details in depth.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.