Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-fp4x-ggrf-wmc6

MEDIUM

H3 has an Open Redirect via Protocol-Relative Path in redirectBack() Referer Validation

Published
Mar 23, 2026
Updated
Mar 23, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

h3npm
35.6Mdownloads / week

Description

Summary

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

Impact

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().

Recommended Fix

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);
}

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmh32.0.1-rc.17&&< 2.0.1-rc.182.0.1-rc.18

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for h3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update h3 to 2.0.1-rc.18 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fp4x-ggrf-wmc6 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-fp4x-ggrf-wmc6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-fp4x-ggrf-wmc6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary 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`: ```typescript export function redirectBack( event
O3 Security · Impact-Aware SCA

Is GHSA-fp4x-ggrf-wmc6 in your dependencies?

O3 detects GHSA-fp4x-ggrf-wmc6 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.