fix(security): harden marketplace SSRF guard (IPv6/redirect/DNS-rebinding)

[diegosouzapw]

Follow-up to #3656, flagged by automated security review (HIGH).

The marketplace custom-URL guard had three SSRF bypasses:

1. IPv6 / AAAA — only dns.resolve4 was checked, so a hostname's private AAAA record (or an IPv6 literal like fc00::1/fe80::1) slipped through.
2. Redirect — raw fetch followed 30x, so a public URL could redirect to an internal one.
3. DNS rebinding — validated once then re-resolved on fetch (TOCTOU).

Reachable only with management auth (requireManagementAuth) + a custom pluginMarketplaceUrl; the remote registry is Phase 2 and the default is the local seed — but per policy internal-only is not a reason to leave SSRF unfixed.

Fix:

• Resolve A + AAAA (dns.lookup {all:true}) and reject if any resolved address is private/loopback/link-local/ULA, via the canonical isPrivateHost (::1, fc00::/7, fe80::/10, IPv4-mapped). Reject literal private hosts up front. Fail-closed on DNS error/empty.
• Fetch via safeOutboundFetch({ guard: "public-only" }) — re-applies the guard and blocks redirects (no public→private 30x pivot), consistent with the rest of the repo's outbound calls.
• 7 regression tests (IPv6 literals, AAAA-resolved-private, rebinding-to-private, protocol, fail-closed, public-accept). lint + typecheck:core clean.

Residual: a pure DNS-rebinding TOCTOU window between the resolution check and undici's connect remains, at parity with the repo-wide isPrivateHost/safeOutboundFetch baseline (no callsite pins IPs); acceptable given the admin-auth-gated, Phase-2-stub surface.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request enhances the SSRF protection for the plugin marketplace by replacing the IPv4-only DNS resolution check with a robust check resolving both IPv4 (A) and IPv6 (AAAA) records using a new lookupFn and isPrivateHost helper. It also updates the fetch mechanism to use safeOutboundFetch with a public-only guard and adds comprehensive unit tests. Feedback highlights an issue where bracketed IPv6 literal hostnames will cause dns.lookup to throw an error, resulting in legitimate public IPv6 URLs being incorrectly rejected. Stripping the brackets from the hostname before validation and resolution is recommended.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

When parsed.hostname is a bracketed IPv6 literal (e.g., [2606:2800:220:1::1]), passing it directly to dns.lookup will cause it to throw an error (such as ENOTFOUND or EINVAL) because dns.lookup expects a raw IP address or hostname without brackets. This error is caught by the try-catch block, causing legitimate public IPv6 literal URLs to be incorrectly rejected as unsafe.

To fix this, we should strip the brackets from parsed.hostname before checking isPrivateHost and passing it to lookupFn.

  // Literal IP hostnames (IPv4 + IPv6, incl. IPv4-mapped) are classified directly.
  const hostname = parsed.hostname.startsWith("[") && parsed.hostname.endsWith("]")
    ? parsed.hostname.slice(1, -1)
    : parsed.hostname;
  if (isPrivateHost(hostname)) {
    return false;
  }
  // Resolve A + AAAA and reject if the hostname maps to any private address.
  try {
    const records = await lookupFn(hostname);
    if (!records.length) return false;
    for (const { address } of records) {
      if (isPrivateHost(address)) return false;
    }