CVE-2026-86205 in h3js
Summary
by MITRE • 09/06/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/06/2026
The vulnerability identified in h3 versions prior to 2.0.1-rc.18 represents a critical web application security flaw centered on improper handling of URL redirection logic within the framework's internal utilities. Specifically, the defect resides in the redirectBack() function, which is designed to facilitate navigation back to the previous page by leveraging information from the HTTP Referer header. This utility fails to adequately sanitize or validate protocol-relative paths contained within the pathname component of the Referer header. In standard web security practices, developers often rely on origin validation checks to ensure that redirects remain within the trusted domain boundaries of the application. However, this implementation contains a logic error where it permits double-slash path segments in URLs that appear to be same-origin during initial validation but are subsequently interpreted by client-side browsers as protocol-relative URIs.
From a technical perspective, the core issue stems from how modern web browsers parse URL strings containing consecutive forward slashes following the scheme or authority components. When an attacker crafts a malicious Referer header value featuring a double-slash sequence immediately after what appears to be the origin, such as https://example.com//evil.com/path, standard validation logic may incorrectly classify this string as belonging to example.com because it matches the host pattern during initial checks. Nevertheless, when the redirectBack() function constructs the Location response header using this unsanitized input, browsers interpret the double slash not merely as a path separator but as an indicator of a protocol-relative URL. This causes the browser to ignore the intended origin and instead treat everything following the slashes as a new authority or host component, effectively directing the user's session to an external domain controlled by the attacker without triggering standard same-origin policy warnings that would typically block such cross-domain navigation attempts.
The operational impact of this vulnerability is significant, particularly in applications where trust boundaries are enforced through client-side redirects based on historical browsing data. An adversary can exploit this flaw to execute a phishing attack or drive-by download scenario by tricking users into navigating away from the legitimate application to a malicious site that mimics the original interface. Because the redirect appears seamless and originates from a trusted domain in the browser's address bar history, victims are less likely to suspect foul play. This technique is particularly dangerous for single-page applications or APIs where session tokens might be exposed during the transition if not properly secured against cross-site request forgery mechanisms that rely on referer validation as an additional layer of defense. The ability to escape the application context undermines the integrity of user sessions and can lead to credential theft, data exfiltration, or further exploitation through social engineering tactics facilitated by the deceptive redirect destination.
This vulnerability aligns with CWE-601, which describes URL Redirection to Untrusted Site (Open Redirect), as it allows an attacker to control the target of a redirection request leading outside the application's trusted scope. Furthermore, from a tactical standpoint relevant to threat intelligence frameworks like MITRE ATT&CK, this behavior corresponds to techniques used in phishing campaigns where attackers leverage legitimate infrastructure to gain user trust before delivering malicious payloads or harvesting credentials. The exploitation vector typically involves crafting specific HTTP requests with manipulated Referer headers, which falls under the broader category of client-side injection and manipulation attacks. To mitigate this risk, developers must implement rigorous input validation that goes beyond simple origin matching. It is essential to parse URLs using robust libraries that correctly handle protocol-relative syntax and ensure that any redirect target is explicitly validated against a whitelist of allowed domains or paths. Additionally, avoiding the use of untrusted user-supplied data for constructing Location headers without thorough sanitization will prevent browsers from misinterpreting path segments as authority components. Upgrading to h3 version 2.0.1-rc.18 or later resolves this issue by correcting the underlying logic in the redirectBack utility to properly escape and validate protocol-relative paths, thereby ensuring that redirects remain strictly within the intended application context.