MCP OAuth Discovery SSRF: A Safe Review Workflow

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

OAuth discovery helps an MCP client locate the information it needs to authenticate. It also creates an outbound network path whose destination may depend on external metadata. Consider a hosted connector service that accepts a customer-supplied MCP server address. The assessment question is whether discovery can make the connector reach destinations outside the service’s approved network policy. This is a network trust-boundary review, not permission to probe internal infrastructure or cloud instance metadata.

Define the boundary before testing

Agree an outbound destination policy with the operator. Identify which component fetches resource metadata, authorization-server metadata, signing information, and any subsequent redirects. Establish approved schemes, ports, hostname rules, resolved address rules, response-size limits, and timeout behavior. Use an owner-controlled public test endpoint and a controlled blocked destination in a nonproduction environment. The infrastructure team should provide the expected network-denial evidence. Avoid real private services; the test must establish a boundary without collecting anything sensitive.

Run a bounded assessment

Exercise the documented connection flow with allowed metadata first. Then use the approved fixtures to test a disallowed destination, a redirect that changes destination class, an oversized metadata response, and an unavailable server. Observe each fetch separately rather than assuming the first URL check applies to the entire sequence. Check whether a background retry worker uses the same network policy. If a library resolves or follows redirects independently, include that component in the observation plan. Stop once the agreed denied behavior or controlled violation is demonstrated.

Keep evidence an engineer can use

Record the initial URL category, resolved destination category, redirect decisions, network policy result, bytes accepted, and final application response. Keep concrete internal addresses out of the public report. A finding should show which controlled request was made and why the expected policy should have denied it. A timeout alone is inconclusive: distinguish application validation, network rejection, server latency, and the assessment harness deadline. Correlating application and egress logs prevents the report from mistaking a failed response for a request that never left the service.

Interpret the result and retest

After remediation, repeat the whole discovery sequence and confirm a legitimate MCP connection still succeeds. Fixes may require both URL validation and a network enforcement layer because metadata fetches can occur outside one code path. Passing these cases does not establish protection against every resolver or proxy behavior. Review outbound fetch changes as part of connector releases. OWASP’s SSRF guidance provides a general reference; apply the deployed MCP and OAuth documentation to the exact discovery flow rather than copying a generic web-form test.

Assessment scope and next steps

This is a proposed defensive assessment workflow, not a finding about a particular product. Use a staging environment, synthetic records, approved test identities, and an agreed stop condition. Record the model, connector, policy, and application versions so a later result can be compared with the same configuration. Unavailable evidence should remain an explicit coverage gap.

Primary reference: OWASP security guidance. The scenarios and acceptance criteria here are editorial recommendations for adapting that background to an authorized assessment.

For a scoped review of these boundaries, explore FailSafe MCP security testing and agentic penetration testing. Agree the specific tools, identities, evidence, and exclusions before purchasing an assessment.