CVE-2026-86205: h3 Framework Open Redirect Vulnerability

CVE-2026-86205 is an open redirect flaw in h3 framework versions before 2.0.1-rc.18 affecting the redirectBack() utility. Attackers exploit inadequate Referer header validation to redirect users to malicious sites. This article covers technical details, affected versions, impact assessment, and mitigation strategies.

CVE-2026-86205 Overview

CVE-2026-86205 is an open redirect vulnerability in the h3 HTTP framework affecting versions prior to 2.0.1-rc.18. The flaw resides in the redirectBack() utility, which fails to sanitize protocol-relative paths present in the Referer header pathname. An attacker can craft a same-origin URL containing a double-slash path segment. This URL passes origin validation but produces a Location header that browsers interpret as a protocol-relative redirect to an attacker-controlled domain. The issue is classified as [CWE-601] Open Redirect and enables phishing and credential harvesting campaigns that abuse the trusted application origin.

Critical Impact
Attackers can redirect authenticated users from a legitimate h3-based application to arbitrary external domains, enabling phishing, session theft, and OAuth flow abuse.

Affected Products

h3 HTTP framework versions before 2.0.1-rc.18
Applications and frameworks embedding vulnerable h3 releases (including Nitro-based and Nuxt server handlers using redirectBack())
Server endpoints that pass user-influenced Referer values to the redirectBack() utility

Discovery Timeline

2026-09-06 - CVE-2026-86205 published to NVD
2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-86205

Vulnerability Analysis

The redirectBack() helper in h3 is designed to send a user back to a previous location by reading the Referer request header and issuing an HTTP redirect. Before performing the redirect, the utility validates that the Referer origin matches the current application origin to prevent cross-site redirection. The origin check succeeds correctly for well-formed URLs, but the pathname portion is passed through to the Location response header without normalization.

When the pathname begins with a double slash such as //attacker.example, the browser treats the resulting Location value as a protocol-relative URL. This causes the client to navigate to the external host under the current scheme. Because the vulnerable request originates from the trusted application, users are unlikely to notice the redirect target, which makes the primitive effective for phishing and OAuth redirect_uri abuse.

Root Cause

The root cause is missing pathname normalization inside redirectBack(). The function trusts the parsed URL object's pathname property after verifying its origin, but it does not collapse leading slashes or reject paths that could be reinterpreted at the HTTP layer. This violates the guidance in [CWE-601] regarding server-controlled redirect targets derived from client input.

Attack Vector

Exploitation requires user interaction. An attacker crafts a link to a vulnerable h3 endpoint with a Referer value pointing to https://victim-app.example//attacker.example/login. When the victim follows the link, the server issues Location: //attacker.example/login, and the browser navigates to attacker.example under HTTPS. The attacker-controlled page can then present a spoofed login form or hijack an OAuth flow. Refer to the GitHub Security Advisory GHSA-fp4x-ggrf-wmc6 and the VulnCheck Advisory for Open Redirect for additional technical detail.

Detection Methods for CVE-2026-86205

Indicators of Compromise

HTTP responses from h3 endpoints containing Location headers that begin with // followed by an external hostname.
Access logs showing inbound requests with Referer values whose pathname starts with a double slash.
Spikes in 302 redirects from application routes that internally call redirectBack().

Detection Strategies

Inspect reverse proxy and web server logs for outbound Location headers matching the regex ^//[^/].
Correlate suspicious Referer header patterns with downstream navigation to unknown domains in browser telemetry.
Enumerate application source for uses of redirectBack() and verify the deployed h3 version is 2.0.1-rc.18 or later.

Monitoring Recommendations

Alert on any redirect response where the Location host does not match an allowlist of trusted internal domains.
Monitor authentication and OAuth callback routes for anomalous redirect destinations following user click-through.
Track user-agent navigation chains that begin at the application origin and terminate on newly registered or low-reputation domains.

How to Mitigate CVE-2026-86205

Immediate Actions Required

Upgrade h3 to version 2.0.1-rc.18 or later across all services and build pipelines.
Audit application code for direct or indirect calls to redirectBack() and enforce a trusted-destination allowlist.
Rotate any OAuth client secrets or session tokens exposed through routes using the vulnerable utility if abuse is suspected.

Patch Information

The h3 maintainers addressed the flaw in version 2.0.1-rc.18 by normalizing the pathname before constructing the Location header. Details are published in the GitHub Security Advisory GHSA-fp4x-ggrf-wmc6. Upgrading is the recommended remediation path.

Workarounds

Wrap redirectBack() with a helper that rejects target pathnames beginning with // or /\.
Validate the resolved redirect URL against an allowlist of internal hostnames before returning the response.
Strip or ignore the Referer header for endpoints that perform server-side redirects when an immediate upgrade is not possible.

bash

# Configuration example: upgrade h3 to the patched release
npm install h3@2.0.1-rc.18
# or
pnpm add h3@2.0.1-rc.18