CVE-2026-63481: Sensitive Information Exposure in Hurl [Cookies] Redirection

CVE-2026-63481 is a sensitive information exposure vulnerability classified as CWE-201 in the Hurl command-line HTTP testing tool. Hurl, developed by Orange-OpenSource, parses and runs HTTP request specifications defined in plain text files. The issue resides in Hurl's client redirection sequence, where the tool fails to isolate custom cookie structures when following cross-origin redirects.

Under standard operating conditions, secure HTTP clients must ensure that sensitive headers are restricted to the origin domain that set them. If a request undergoes an HTTP redirection to a foreign host, standard cookies and authentication parameters must be stripped. While Hurl successfully executes this boundary enforcement for conventional raw HTTP headers, it neglects custom internal data structures.

This behavior exposes test suites to credential theft when executing redirects configured via the inline options or command-line parameters. An attacker who controls an endpoint or can induce a redirect can receive the active cookies intended for the original target. This vulnerability affects all Hurl versions up to and including 8.0.1 and has been fully remediated in version 8.1.0.

The fundamental flaw in CVE-2026-63481 is located in the client redirection loop within packages/hurl/src/http/client.rs. Hurl leverages the Rust bindings for libcurl to handle network requests and follow HTTP redirects. By default, libcurl contains logic to strip conventional Cookie and Authorization headers when navigating cross-origin redirects. Hurl replicates this protection inside its client layer by manually filtering out these headers when same_host is evaluated as false.

However, Hurl provides two distinct ways to define cookies for automated tests. Users can pass cookies directly via standard raw HTTP headers, or they can use the dedicated [Cookies] parser block. Cookies defined in the standard raw headers are serialized directly into the outgoing header vector, making them subject to the manual filter. Cookies defined via the [Cookies] block are stored separately within a custom RequestSpec.cookies data vector.

When a redirection occurs, Hurl re-evaluates the host configuration and constructs a new request specification. The client removes raw headers such as Authorization and Cookie from the header vector. However, the client fails to inspect or clear the RequestSpec.cookies field. Consequently, the custom cookie container is passed completely intact into the redirected request, causing the client to reissue these credentials to the foreign host.

Analyzing the vulnerable code path in packages/hurl/src/http/client.rs reveals the exact mechanism of the leak. During the redirection sequence, Hurl re-evaluates the original request specification and clones its fields. When the hostname changes and the target is not trusted, standard headers are filtered, but the cookies vector is copied directly.

// Vulnerable logic in Hurl <= 8.0.1
let mut headers = request_spec.headers;
if !same_host {
    headers.retain(|h| !h.name_eq(AUTHORIZATION));
    headers.retain(|h| !h.name_eq(COOKIE));
    options.user = None;
}
 
let redirect_request_spec = RequestSpec {
    url: redirect_url,
    headers,
    cookies: request_spec.cookies, // Vulnerable: unchanged vector is carried over
    body,
    ..
};

The fix introduced in version 8.1.0 changes this logic by copying the cookie vector into a mutable variable and explicitly purging its contents if a cross-origin redirect is encountered without explicit user trust overrides.

// Patched logic in Hurl 8.1.0
let mut headers = request_spec.headers;
let mut cookies = request_spec.cookies;
 
if !same_host && !options.location_trusted {
    headers.retain(|h| !h.name_eq(AUTHORIZATION));
    headers.retain(|h| !h.name_eq(COOKIE));
    cookies.clear(); // Fixed: Clears structured cookies for foreign domains
    options.user = None;
}
 
let redirect_request_spec = RequestSpec {
    url: redirect_url,
    headers,
    cookies,
    body,
    ..
};

Evaluating the completeness of this fix shows that it directly addresses the identified leakage route. However, teams must recognize that utilizing the --location-trusted flag overrides this security check. Under trusted-location settings, both standard headers and custom cookie structures are deliberately preserved across redirects, meaning that operational vigilance is required when executing tests with this flag enabled.

An attacker can exploit this vulnerability by establishing a malicious server or leveraging an existing open redirect on a trusted target. The attack depends on a Hurl test file containing both a [Cookies] block and active redirect-following options. A representative redirection and compromise path is shown below.

When Hurl initiates the HTTP session with the trusted server, it includes the credentials specified in the custom parser block. If the trusted server returns an HTTP 302 Found response directing Hurl to an external, attacker-controlled host, the client follows the pointer. Because the client fails to clear the custom cookies vector, it establishes a new connection with the attacker's host and transmits the sensitive cookies.

The attacker's web server captures the incoming request and logs the HTTP headers. Since the client reconstructed the cookie from its internal vector, the attacker successfully retrieves the session cookies. This sensitive information can then be used to authenticate as the compromised user or run authorized API operations against the target platform.

The impact of CVE-2026-63481 is classified as high-severity information disclosure. Because Hurl is often used within continuous integration and continuous deployment pipelines, the tool routinely handles elevated administrative tokens and API keys. A leak of these credentials from a pipeline environment can grant attackers access to sensitive internal infrastructure.

The vulnerability is assigned a CVSS v4.0 base score of 6.9, reflecting network-level exploitability and high confidentiality impact on the affected system. It requires active user interaction, as an operator must run a test file that initiates a request to a compromised target. Direct impact on the integrity and availability of the client host is not present, as the vulnerability does not enable local code execution.

EPSS tracking indicates a score of 0.00467, which represents a low current probability of automated exploitation in the wild. However, the operational threat remains substantial for environments executing tests against external APIs or third-party webhooks. Because test results are frequently collected in centralized logging systems, leaked headers may also be stored permanently in cleartext logs.

The primary remediation strategy is upgrading the Hurl binary to version 8.1.0 or higher. The official release includes the code changes required to strip custom cookie structures during cross-origin redirections. Security teams should scan production test environments and update the tool within their package managers or container configurations.

For systems where upgrading is not immediately possible, operators should convert all [Cookies] parser blocks into standard HTTP Cookie headers. Standard raw headers are properly processed and stripped by the Hurl client during redirections. Alternatively, teams can disable the automatic redirect-following option (location: true or --location flag) and manually validate redirection chains.

Finally, development teams must avoid using the --location-trusted command-line argument unless absolutely necessary. This argument explicitly bypasses the boundary checks, forcing Hurl to retain credentials across different origins. Restricting its use reduces the surface area for accidental credential exposure.