GHSA-vhj5-x93p-67jw: Host Header Poisoning and Open Redirect in actix-web-lab

The actix-web-lab package is a collection of experimental extractors and middleware for the Actix Web framework in Rust. It provides utility functions that often graduate to the main actix-web crate. Among these utilities are the RedirectHttps, RedirectToWww, and RedirectToNonWww middlewares, which handle automatic URL redirection for canonicalization and security upgrades.

These specific middlewares are vulnerable to host header poisoning (CWE-601). They construct absolute redirect URLs using unvalidated host information derived from the incoming HTTP request. This information is typically extracted from the Host header or forwarding headers like X-Forwarded-Host.

Because the framework implicitly trusts these headers without validation, an attacker can supply arbitrary domains. The middleware incorporates the malicious domain into the Location header of the HTTP response. This behavior creates an Open Redirect vulnerability, permitting attackers to redirect users to untrusted external sites.

The root cause of this vulnerability is the direct use of the req.connection_info().host() method to build absolute URIs for HTTP redirection. The connection_info() function extracts the host from the request headers, which are entirely user-controlled.

When the middleware processes an incoming request, it evaluates whether a redirect is necessary. For example, RedirectHttps checks if the current request scheme is HTTP. If a redirect is required, the middleware retrieves the host string and concatenates it with the requested path to form the target URL.

No sanitization or validation is performed on the host string before it is interpolated into the Location header. If the server environment passes the Host or X-Forwarded-Host headers directly to the application without a strictly configured reverse proxy, the application inherits the manipulated values. This architectural reliance on client-provided headers for sensitive routing decisions enables the exploitation.

Prior to version 0.26.0, the middleware implementations instantiated redirects by blindly trusting the connection info. The vulnerable logic effectively extracted the host and path, combined them, and issued a 307 or 308 redirect status code.

// Vulnerable logic pattern in actix-web-lab redirect middleware
let host = req.connection_info().host();
let path = req.uri().path();
let target_uri = format!("https://{}{}", host, path);
return Ok(Redirect::to(target_uri).respond_to(&req));

The patch introduced in commit 142c28b82eb59b67445a859a2a9b75e01a9964ee resolves this by adding a HostAllowlist structure and a validation routine. The reject_untrusted_host function verifies the incoming host against the configured allowlist.

// New validation function introduced in src/redirect_host.rs
pub(crate) fn reject_untrusted_host(
    configured_allowlist: Option<&HostAllowlist>,
    host: &str,
) -> Option<HttpResponse<()>> {
    if configured_allowlist.is_some_and(|allowlist| !allowlist.contains(host)) {
        return Some(HttpResponse::with_body(StatusCode::BAD_REQUEST, ()));
    }
    None
}

If an allowlist is present and the host does not match, the middleware aborts the redirect and returns a 400 Bad Request. This strict validation prevents arbitrary domains from entering the response headers.

Exploitation requires an attacker to identify a target application utilizing the vulnerable actix-web-lab middleware. The attacker must then craft an HTTP request targeting an endpoint that triggers the redirection logic, such as an HTTP endpoint when RedirectHttps is enforced.

The attacker modifies the HTTP request to include a malicious Host header. If the target server sits behind a reverse proxy that normalizes the Host header, the attacker may alternative inject an X-Forwarded-Host header, provided the proxy forwards it and the Actix application is configured to trust it.

GET /login HTTP/1.1
Host: malicious-domain.com

The vulnerable middleware processes this request, constructs the absolute URI using the malicious domain, and returns an HTTP 307 or 308 redirect. The victim's browser, upon receiving this response, automatically navigates to the attacker-controlled server.

HTTP/1.1 307 Temporary Redirect
Location: https://malicious-domain.com/login

The primary impact of this vulnerability is an Open Redirect, which facilitates sophisticated phishing and social engineering campaigns. Attackers can distribute seemingly legitimate links pointing to the trusted application domain. When victims click these links, the server explicitly instructs their browsers to navigate to an attacker-controlled site.

This mechanism degrades user trust and bypasses security training that teaches users to verify the initial domain in a URL. The vulnerability holds a CVSS v3.1 score of 6.1 (Medium), reflecting the requirement for user interaction and the limited direct impact on the server's confidentiality or integrity.

While the server infrastructure itself is not compromised, the application becomes an active participant in attacks against its user base. This can lead to credential theft if the attacker's site perfectly mimics the target application's authentication portal.

To remediate this vulnerability, developers must upgrade the actix-web-lab crate to version 0.26.0 or later. However, upgrading the dependency alone is insufficient. The patch is not secure by default and requires explicit configuration to enable the protection.

Developers must implement the .allow_hosts() method on all instances of the redirect middleware. This method accepts an array of trusted domains. Applications failing to configure this allowlist remain vulnerable even after the crate is updated.

use actix_web_lab::middleware::RedirectHttps;
 
App::new()
    .wrap(RedirectHttps::default().allow_hosts(["example.com", "www.example.com"]))

In environments where code changes cannot be immediately deployed, operators can mitigate the flaw at the reverse proxy layer. Proxies like Nginx or HAProxy should be configured to strictly validate the Host header against known virtual hosts and sanitize untrusted X-Forwarded-Host headers before they reach the Actix application.