h3 before 2.0.1-rc.18 Open Redirect via redirectBack()
cve-program · CVE-2026-86205
Publishedh3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Read the publisher's advisoryeuvd · EUVD-2026-72105
Publishedh3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Read the publisher's advisorynvd · CVE-2026-86205
Publishedh3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Read the publisher's advisoryosv · GHSA-fp4x-ggrf-wmc6
Published## 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: 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 ```bash # 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: ```typescript 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); } ```
Read the publisher's advisoryAffected versions, risk and source history
Exploitation and risk
Source statusCISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.
Which CVEs have scores here?
This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.
No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.
cve-program · CVE-2026-86205
Publishedh3 before 2.0.1-rc.18 Open Redirect via redirectBack()
h3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
- Source published
- 6 Sep 2026 12:00:25 UTC
- Source modified
- 8 Sep 2026 13:28:55 UTC
- Saved here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
CVSS 3.1 · 5.4 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
euvd · EUVD-2026-72105
Publishedh3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash pat…
h3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Additional publisher context
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Sep 6, 2026, 12:00:25 PM
dateUpdated: Sep 8, 2026, 1:28:55 PM
- Source published
- Sep 6, 2026, 12:00:25 PM (timezone not stated)
- Source modified
- Sep 8, 2026, 1:28:55 PM (timezone not stated)
- Saved here
- 13 Nov 2026 18:04:11 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
EUVD CVSS 4.0 · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
nvd · CVE-2026-86205
Publishedh3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash pat…
h3 versions before 2.0.1-rc.18 contain an open redirect vulnerability in the redirectBack() utility that fails to sanitize protocol-relative paths in the Referer header pathname. Attackers can craft a same-origin URL with a double-slash path segment that passes origin validation but produces a Location header interpreted by browsers as a protocol-relative redirect to an external domain.
Additional publisher context
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Awaiting Analysis
Weakness classifications: CWE-601
Original publisher date fields
published: 2026-09-06T12:17:15.277
lastModified: 2026-09-08T20:00:18.870
- Source published
- 6 Sep 2026 12:17:15 UTC
- Source modified
- 8 Sep 2026 20:00:18 UTC
- Saved here
- 25 Oct 2026 16:19:16 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 4.0 · [email protected] · Secondary · 5.3 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
CVSS 3.1 · [email protected] · Secondary · 5.4 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
osv · GHSA-fp4x-ggrf-wmc6
PublishedH3 has an Open Redirect via Protocol-Relative Path in redirectBack() Referer Validation
## 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: 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 ```bash # 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: ```typescript 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); } ```
- Source published
- 23 Mar 2026 21:48:24 UTC
- Source modified
- 10 Sep 2026 03:51:00 UTC
- Saved here
- 24 Oct 2026 13:17:17 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Publisher rating · MODERATE