GHSA-FP4X-GGRF-WMC6

The redirectBack() utility in h3 validates that the Referer header shares the same origin as the request before using its pathname as the redirect Location. However, the pathname is not sanitized for protocol-relative paths (starting with //). An attacker can craft a same-origin URL with a double-slash path segment that passes the origin check but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.

Details

The vulnerable code is in src/utils/response.ts:89-97:

export function redirectBack(
  event: H3Event,
  opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},
): HTTPResponse {
  const referer = event.req.headers.get("referer");
  let location = opts.fallback ?? "/";
  if (referer && URL.canParse(referer)) {
    const refererURL = new URL(referer);
    if (refererURL.origin === event.url.origin) {
      // BUG: pathname can be "//evil.com/path" which browsers interpret
      // as a protocol-relative URL
      location = refererURL.pathname + (opts.allowQuery ? refererURL.search : "");
    }
  }
  return redirect(location, opts.status);
}

The root cause is a discrepancy between how the WHATWG URL parser and browsers handle double-slash paths:

1. new URL("http://target.com//evil.com/path").origin → "http://target.com", origin check passes
2. new URL("http://target.com//evil.com/path").pathname → "//evil.com/path", extracted as redirect location
3. Browser receives Location: //evil.com/path → interprets as protocol-relative URL → redirects to evil.com

Attack scenario: The attacker shares a link like http://target.com//evil.com/page. If the target application has catch-all routes (common in SPAs built with h3/Nitro), the app serves its page at that URL. When the user navigates to an endpoint calling redirectBack(), the browser sends Referer: http://target.com//evil.com/page. The origin check passes, and the user is redirected to evil.com, which can host a phishing page mimicking the target.

PoC

# 1. Create a minimal h3 app with redirectBack
cat > /tmp/h3-redirect-poc.ts << 'SCRIPT'
import { H3, redirectBack } from "h3";

const app = new H3();
app.post("/submit", (event) => redirectBack(event));

const res = await app.fetch(new Request("http://localhost/submit", {
  method: "POST",
  headers: { referer: "http://localhost//evil.com/steal" }
}));

console.log("Status:", res.status);
console.log("Location:", res.headers.get("location"));
// Expected: a same-origin path
// Actual: "//evil.com/steal", protocol-relative redirect to evil.com
SCRIPT

# 2. Verify URL parsing behavior
node -e "
const u = new URL('http://localhost//evil.com/steal');
console.log('origin:', u.origin);         // http://localhost
console.log('pathname:', u.pathname);     // //evil.com/steal
console.log('origin matches localhost:', u.origin === 'http://localhost');  // true
"
# Output:
# origin: http://localhost
# pathname: //evil.com/steal
# origin matches localhost: true

An attacker can redirect users from a trusted application to an attacker-controlled domain. This enables:

• Credential phishing: Redirect to a lookalike login page to harvest credentials
• OAuth token theft: In OAuth flows using redirectBack(), steal authorization codes by redirecting to an attacker's callback
• Trust exploitation: Users see the initial link points to the trusted domain, lowering suspicion

The vulnerability requires no authentication and affects any endpoint using redirectBack().

Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites. Typical impact: phishing and credential harvesting via a trusted domain.

GHSA-FP4X-GGRF-WMC6 has a CVSS score of 5.4 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.0.1-rc.18); upgrading removes the vulnerable code path.

Kodem intelligence

Sanitize the extracted pathname to prevent protocol-relative URLs. In src/utils/response.ts, after extracting the pathname from the referer:

export function redirectBack(
  event: H3Event,
  opts: { fallback?: string; status?: number; allowQuery?: boolean } = {},
): HTTPResponse {
  const referer = event.req.headers.get("referer");
  let location = opts.fallback ?? "/";
  if (referer && URL.canParse(referer)) {
    const refererURL = new URL(referer);
    if (refererURL.origin === event.url.origin) {
      let pathname = refererURL.pathname;
      // Prevent protocol-relative open redirect (e.g., "//evil.com")
      if (pathname.startsWith("//")) {
        pathname = "/" + pathname.replace(/^\/+/, "");
      }
      location = pathname + (opts.allowQuery ? refererURL.search : "");
    }
  }
  return redirect(location, opts.status);
}

1. What is GHSA-FP4X-GGRF-WMC6? GHSA-FP4X-GGRF-WMC6 is a medium-severity open redirect vulnerability in h3 (npm), affecting versions = 2.0.1-rc.17. It is fixed in 2.0.1-rc.18. Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites.
2. How severe is GHSA-FP4X-GGRF-WMC6? GHSA-FP4X-GGRF-WMC6 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of h3 are affected by GHSA-FP4X-GGRF-WMC6? h3 (npm) versions = 2.0.1-rc.17 is affected.
4. Is there a fix for GHSA-FP4X-GGRF-WMC6? Yes. GHSA-FP4X-GGRF-WMC6 is fixed in 2.0.1-rc.18. Upgrade to this version or later.
5. Is GHSA-FP4X-GGRF-WMC6 exploitable, and should I be worried? Whether GHSA-FP4X-GGRF-WMC6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-FP4X-GGRF-WMC6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-FP4X-GGRF-WMC6? Upgrade h3 to 2.0.1-rc.18 or later.