fix(mcp): pin outbound connections to IPv4 to avoid unreachable-IPv6 hangs

[waleedlatif1]

The real root cause (empirically confirmed)

The MCP "connecting forever" / tool-discovery 30s timeouts in production — affecting Gauge, Exa, and PlanetScale alike — were caused by IP-family pinning, not OAuth or HTTP/2 (which the earlier PRs fixed but were different layers).

The chain, every link verified against production:

1. SSRF protection pins each outbound connection to a single resolved IP (createPinnedLookup), which strips Happy Eyeballs' IPv4 fallback.
2. dns.lookup(host, { verbatim: true }) returns the IPv6 address first for Cloudflare-fronted dual-stack hosts — verified: app.withgauge.com → 2606:4700:…, api.exa.ai → 2606:4700:….
3. Production's app subnets have zero IPv6 egress — no IPv6 CIDR, IPv4-only via NAT Gateway (AWS NAT Gateways are IPv4-only). Verified on both subnets + route tables.
4. So the connection pinned to IPv6 connects into a void and hangs → the SDK's 30s timeout fires (AbortError, durationMs=30002). Intermittent because the resolver rotates A/AAAA order (works on retry when it picks IPv4).

This explains everything that didn't add up: why #5797 (h1.1) didn't fix it (protocol-independent), and why it never reproduced locally (dev machines have IPv6 egress).

Empirical proof (undici, pinned lookup):

pin IPv6-blackhole ONLY (current behavior) → FAIL after 8001ms (TimeoutError) ← the prod hang
prefer IPv4 / include IPv4 in the set → status 200 in ~600ms ← reachable

Fix

At both pinned-resolution sites — validateMcpServerSsrf (MCP) and validateUrlWithDNS (providers / A2A / SMTP, same latent bug) — resolve all addresses ({ all: true, verbatim: true }) and prefer an IPv4 address; IPv6-only hosts still pin their sole address. This keeps the single-IP pinning API and threading untouched (near-zero blast radius) and SSRF validation of the pinned IP is unchanged.

Verified end-to-end: app.withgauge.com and api.exa.ai now pin their IPv4 address instead of the unreachable IPv6.

Type of Change

• Bug fix

Testing

• Full lib/mcp suite green (374); lib/core/security green; tsc + biome clean.
• Added tests: dual-stack host prefers IPv4; IPv6-only host pins its sole address.
• The definitive confirmation is re-testing on staging/prod once deployed.

Note

A fuller fix (pin the validated set of all resolved IPs and let undici do Happy Eyeballs, so it's egress-agnostic) is a good follow-up, but it threads string → string[] through ~10 security-critical sites; preferring IPv4 fixes the confirmed bug now with minimal risk.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 21, 2026 5:13am

[cursor]

PR Summary

Medium Risk
Touches security-critical DNS pinning for MCP and general outbound URL validation; behavior change is narrow (address family preference) but affects all pinned connections to dual-stack hosts.

Overview
Fixes production MCP connection hangs (~30s timeouts) on dual-stack hosts when SSRF pinning chose an IPv6 address first (dns.lookup with verbatim: true) while egress is IPv4-only (e.g. AWS NAT), so pinned outbound traffic never completed.

validateMcpServerSsrf and validateUrlWithDNS now resolve all addresses ({ all: true, verbatim: true }) and prefer an IPv4 entry for the pinned IP; IPv6-only hosts still use their sole address. SSRF checks still run on the chosen address; only selection order changed.

Tests mock the multi-record lookup shape and add cases for dual-stack (IPv4 preferred) and IPv6-only pinning.

^{Reviewed by Cursor Bugbot for commit a866409. Configure here.}

[greptile-apps]

Greptile Summary

This PR changes pinned outbound connections to prefer IPv4 while preserving IPv6-only resolution. The main changes are:

• Resolve every address before selecting the pinned IP.
• Prefer IPv4 for dual-stack MCP and general outbound URLs.
• Add MCP tests for dual-stack and IPv6-only hosts.

Confidence Score: 5/5

This looks safe to merge.

• Both validation paths keep the existing SSRF checks and pinning behavior.
• IPv6 remains available when DNS returns no IPv4 address.
• No additional blocking issue was found in the updated code.

Important Files Changed

Filename	Overview
apps/sim/lib/core/security/input-validation.server.ts	Resolves all DNS addresses and prefers IPv4 for pinned outbound requests.
apps/sim/lib/mcp/domain-check.ts	Applies IPv4-preferred address selection to MCP SSRF validation.
apps/sim/lib/mcp/domain-check.test.ts	Updates DNS mocks and tests dual-stack preference and IPv6-only fallback.

_{Reviews (2): Last reviewed commit: "chore(mcp): trim inline comments on the ..." | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit a866409. Configure here.}