fix(mcp): pin outbound connections to IPv4 to avoid unreachable-IPv6 hangs by waleedlatif1 · Pull Request #5798 · simstudioai/sim

waleedlatif1 · 2026-07-21T05:08:25Z

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:

SSRF protection pins each outbound connection to a single resolved IP (createPinnedLookup), which strips Happy Eyeballs' IPv4 fallback.
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:….
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.
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)

…hangs Root cause of the MCP 'connecting forever' / tool-discovery timeouts in production: SSRF pinning forces each outbound connection to a single resolved IP, which strips Happy Eyeballs' IPv4 fallback. dns.lookup(verbatim) returns the IPv6 address first for Cloudflare-fronted dual-stack hosts (Gauge, api.exa.ai), so the connection was pinned to IPv6 — but the production app subnets have no IPv6 egress (AWS NAT gateways are IPv4-only), so the pinned IPv6 connection connects into a void and hangs until the 30s timeout. Intermittent because the resolver rotates A/AAAA order; works on retry when it happens to pick IPv4. This is why h1.1 (#5797) did not fix it (protocol-independent) and why it never reproduced locally (dev machines have IPv6 egress). Empirically verified: pinning only the IPv6 address times out; preferring the IPv4 address connects in ~600ms. Fix: at both pinned-resolution sites (validateMcpServerSsrf and validateUrlWithDNS) resolve all addresses and prefer an IPv4 one; IPv6-only hosts still pin their sole address. No signature/threading changes; SSRF validation of the pinned IP is unchanged.

vercel · 2026-07-21T05:08:32Z

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 · 2026-07-21T05:08:36Z

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 · 2026-07-21T05:10:40Z

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 · 2026-07-21T05:13:43Z

@greptile

waleedlatif1 · 2026-07-21T05:13:44Z

@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.}

…5799) Same class of bug fixed for MCP in #5798: SSRF pinning forces a single resolved IP, which strips Happy Eyeballs' IPv4 fallback. dns.lookup(verbatim) returns the IPv6 address first for dual-stack hosts, so a database host or 1Password Connect server that is dual-stack gets pinned to IPv6 — unreachable on IPv4-only egress (AWS NAT gateways) and hangs until timeout. validateDatabaseHost and validateConnectServerUrl now resolve all addresses and prefer IPv4; IPv6-only hosts still pin their sole address. SSRF validation of the pinned IP is unchanged (the selected address is the one validated and pinned).

greptile-apps Bot reviewed Jul 21, 2026

View reviewed changes

Comment thread apps/sim/lib/core/security/input-validation.server.ts

chore(mcp): trim inline comments on the IPv4-preference fix

a866409

vercel Bot temporarily deployed to Preview July 21, 2026 05:13 Inactive

cursor Bot reviewed Jul 21, 2026

View reviewed changes

waleedlatif1 mentioned this pull request Jul 21, 2026

fix(security): prefer IPv4 when pinning DB and 1Password connections #5799

Merged

6 tasks

waleedlatif1 merged commit d381eef into staging Jul 21, 2026
20 checks passed

waleedlatif1 deleted the fix/mcp-pin-ipv4-egress branch July 21, 2026 05:29

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

fix(mcp): pin outbound connections to IPv4 to avoid unreachable-IPv6 hangs#5798
waleedlatif1 merged 2 commits into
stagingfrom
fix/mcp-pin-ipv4-egress

waleedlatif1 commented Jul 21, 2026

Uh oh!

vercel Bot commented Jul 21, 2026 •

edited

Loading

Uh oh!

cursor Bot commented Jul 21, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Jul 21, 2026 •

edited

Loading

Uh oh!

Uh oh!

waleedlatif1 commented Jul 21, 2026

Uh oh!

waleedlatif1 commented Jul 21, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

waleedlatif1 commented Jul 21, 2026

The real root cause (empirically confirmed)

Fix

Type of Change

Testing

Note

Checklist

Uh oh!

vercel Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cursor Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

Uh oh!

greptile-apps Bot commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Uh oh!

Uh oh!

waleedlatif1 commented Jul 21, 2026

Uh oh!

waleedlatif1 commented Jul 21, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

vercel Bot commented Jul 21, 2026 •

edited

Loading

cursor Bot commented Jul 21, 2026 •

edited

Loading

greptile-apps Bot commented Jul 21, 2026 •

edited

Loading