Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-09-06T12:17:15.277Z",
  "pubdate": "2026-09-06T12:17:15.277Z",
  "executiveSummary": "The h3 library, specifically versions prior to 2.0.1-rc.18, is susceptible to an open redirect vulnerability located within the redirectBack() utility.\nThis flaw arises from inadequate sanitization of protocol-relative paths extracted from the Referer header, allowing an attacker to bypass origin validation.\nBy manipulating the URL structure, an attacker can craft a payload that forces a user's browser to execute a redirect to an arbitrary external domain.\nThe primary risk involves facilitating phishing, credential theft, or the distribution of malicious content by leveraging the trusted context of the original domain.\nExploitation requires the attacker to influence the Referer header or craft a specific input that the application processes through the vulnerable utility.\nThe vulnerability is classified as an open redirect, which poses significant security risks in authentication flows or user redirection mechanisms.",
  "technicalDetails": "The vulnerability resides in the redirectBack() utility of the h3 library, which is designed to redirect users to the location specified by the Referer header.\nThe root cause is a failure to properly sanitize protocol-relative URLs, specifically those beginning with double slashes (//), which are interpreted by modern web browsers as absolute URLs targeting the protocol of the current page but directed to a different host.\nThe library performs origin validation to ensure redirects remain within the same domain. However, the validation logic fails to account for how browsers interpret the double-slash syntax when provided in the path segment.\nAn attacker can exploit this by crafting a URL that presents as a same-origin request to the validation logic but contains a payload formatted with a double-slash, such as //attacker.com.\nWhen the redirectBack() utility processes this input, the origin check incorrectly concludes that the path is local or legitimate because it does not strictly enforce schema-relative path sanitization.\nThe application subsequently constructs a Location HTTP header using the attacker-controlled input. Upon receiving the response, the browser processes the Location header starting with // as a protocol-relative absolute URL, navigating the user to the attacker-controlled host rather than the intended same-origin destination.\nThis behavior bypasses standard security expectations for redirect utilities, as the server-side logic inadvertently facilitates unauthorized redirection to external entities.\nThe vulnerability affects h3 versions before 2.0.1-rc.18. Exploitation does not necessarily require the attacker to have administrative privileges; it relies on the ability to trigger a request to the vulnerable endpoint with a manipulated Referer header or manipulated input parameter that the application uses to derive the redirect target.\nSuccessful exploitation enables an attacker to direct users to malicious sites, potentially aiding in cross-site scripting (XSS) if the malicious site is configured to exploit further, or capturing sensitive information through phishing campaigns disguised as legitimate application redirects."
}