Skip to content

fix(coderd): block SSRF in MCP OAuth2 discovery and client registration - #27989

Draft
ThomasK33 wants to merge 1 commit into
mainfrom
tk/codagt-784-remediate-cdm-02-002-mcp-oauth2-discovery-ssrf
Draft

fix(coderd): block SSRF in MCP OAuth2 discovery and client registration#27989
ThomasK33 wants to merge 1 commit into
mainfrom
tk/codagt-784-remediate-cdm-02-002-mcp-oauth2-discovery-ssrf

Conversation

@ThomasK33

Copy link
Copy Markdown
Member

MCP OAuth2 auto-discovery and Dynamic Client Registration fetched attacker-influenced URLs (the MCP server URL plus any endpoints or redirects it advertises) with a plain HTTP client. A hostile MCP server could redirect these discovery fetches to internal destinations such as cloud metadata (169.254.169.254) or loopback-only services, with part of the response surfacing through the API error detail (Cure53 CDM-02-002, partially-blind SSRF).

All discovery and registration traffic now goes through a dedicated SSRF-guarded HTTP client: each hostname is resolved once, destinations in private, loopback, link-local, multicast, unspecified, and special-use ranges are rejected, and a validated IP is dialed directly so DNS rebinding cannot swap in a private address between validation and connect. Redirects pass through the same guarded dialer, IPv4-mapped IPv6 literals are unmapped before matching, and the client never uses a proxy because the destination IP would be invisible to the dialer. Manually configured OAuth2 endpoints are unaffected; only auto-discovery against internal addresses now fails by design. coderd.Options gains an internal allowlist seam so tests can serve mock MCP servers on loopback; this is intentionally not user-facing configuration.

Regression tests assert that an internal loopback canary receives zero requests across redirect scenarios (discovery GET, registration POST, metadata IP, DNS-resolving hostnames) at both the unit and API level.

Closes CODAGT-784.


Generated with mux

MCP OAuth2 auto-discovery and Dynamic Client Registration fetched
attacker-influenced URLs (the MCP server URL and any endpoints or
redirects it advertises) with a plain HTTP client. A hostile MCP
server could redirect these fetches to internal addresses such as
cloud metadata (169.254.169.254) or loopback services and partially
read the responses (Cure53 CDM-02-002).

Route all discovery traffic through a dedicated client that resolves
each hostname once, rejects destinations in private, loopback,
link-local, multicast, unspecified, and special-use ranges, and dials
a validated IP directly so DNS rebinding cannot swap in a private
address after validation. Redirects pass through the same guarded
dialer, IPv4-mapped IPv6 literals are unmapped before matching, and
the client never uses a proxy because the destination IP would be
invisible to the dialer. Manual OAuth2 configuration is unaffected.

coderd.Options gains an internal allowlist seam so tests can serve
mock MCP servers on loopback; there is intentionally no user-facing
configuration to bypass the guard.
@linear-code

linear-code Bot commented Aug 10, 2026

Copy link
Copy Markdown

CODAGT-784

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant