CVE-2026-34835: Rack Auth Bypass Vulnerability

CVE-2026-34835 Overview

A host header parsing vulnerability has been discovered in Rack, a modular Ruby web server interface. The vulnerability exists in Rack::Request which parses the Host header using an AUTHORITY regular expression that accepts characters not permitted in RFC-compliant hostnames, including /, ?, #, and @. Because req.host returns the full parsed value, applications that validate hosts using naive prefix or suffix checks can be bypassed, leading to host header poisoning attacks.

Critical Impact

Applications using req.host, req.url, or req.base_url for link generation, redirects, or origin validation are vulnerable to host header poisoning, potentially enabling phishing attacks, cache poisoning, and authentication bypass.

Affected Products

• Rack versions 3.0.0.beta1 to before 3.1.21
• Rack versions 3.2.0 to before 3.2.6

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-34835 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34835

Vulnerability Analysis

This vulnerability falls under CWE-1286 (Improper Validation of Syntactic Correctness of Input). The core issue lies in how Rack's Rack::Request class parses the HTTP Host header. The implementation uses an AUTHORITY regular expression pattern that is more permissive than what RFC standards allow for valid hostnames.

When parsing the Host header, the regex accepts special characters including /, ?, #, and @ that should not appear in legitimate hostnames. This permissive parsing creates a security gap where attackers can craft malicious Host header values that pass through Rack's parsing but contain embedded malicious content.

Applications commonly implement host validation using simple string operations like checking if the host starts with or ends with an expected domain. When req.host returns these non-compliant values, the validation logic can be tricked into accepting malicious hosts that appear to match the expected pattern but contain additional attacker-controlled content.

Root Cause

The root cause is the overly permissive AUTHORITY regular expression used in Rack::Request for Host header parsing. This regex fails to properly validate that the hostname conforms to RFC standards, allowing special characters that can be leveraged for injection attacks. The parsed value is then returned without sanitization through req.host, req.url, and req.base_url methods.

Attack Vector

An attacker can exploit this vulnerability by sending HTTP requests with crafted Host headers containing special characters. The attack is network-based and requires no authentication or user interaction.

For example, an attacker could send a Host header like trusted-domain.com@evil.com or trusted-domain.com#evil.com. If the application validates hosts using a suffix check like host.end_with?('trusted-domain.com'), this malicious host would pass validation. The application might then use this poisoned host value for:

• Generating password reset links that redirect to attacker-controlled domains
• Creating OAuth callback URLs pointing to malicious endpoints
• Generating absolute URLs in cached content that serve malicious links to other users
• Bypassing same-origin validation checks

See the GitHub Security Advisory for additional technical details.

Detection Methods for CVE-2026-34835

Indicators of Compromise

• Unusual characters in Host headers including @, #, ?, and / in web server access logs
• Password reset or authentication emails containing unexpected domains
• Redirect responses pointing to external domains when internal redirects are expected
• Cache entries with modified URL origins

Detection Strategies

• Implement logging and alerting for Host headers containing RFC-invalid characters
• Monitor for anomalous redirect patterns in application logs
• Review web server logs for requests with malformed Host headers
• Deploy web application firewall (WAF) rules to detect Host header injection attempts

Monitoring Recommendations

• Enable detailed request logging including full Host header values
• Set up alerts for requests where the Host header contains special characters (@, #, ?, /)
• Monitor for password reset or account recovery emails with unexpected URLs
• Review application behavior when handling requests with non-standard Host headers

How to Mitigate CVE-2026-34835

Immediate Actions Required

• Upgrade Rack to version 3.1.21 or later for the 3.1.x branch
• Upgrade Rack to version 3.2.6 or later for the 3.2.x branch
• Review application code that uses req.host, req.url, or req.base_url for host validation
• Implement strict hostname validation using allowlists rather than pattern matching

Patch Information

The Rack development team has released patched versions that properly validate Host header values according to RFC standards. Users should upgrade to:

• 3.1.21 for applications using the 3.1.x release branch
• 3.2.6 for applications using the 3.2.x release branch

For more information, refer to the GitHub Security Advisory.

Workarounds

• Implement strict hostname allowlisting at the application layer before using req.host values
• Configure reverse proxies or load balancers to reject requests with invalid Host headers
• Use exact string matching for host validation instead of prefix/suffix checks
• Validate Host headers against a fixed set of expected values at the middleware level

# Example: Nginx configuration to validate Host headers
# Add to server block to reject requests with invalid characters
if ($host ~* [/@#?]) {
    return 400;
}

# Alternatively, use an allowlist approach
set $valid_host 0;
if ($host = "trusted-domain.com") {
    set $valid_host 1;
}
if ($host = "www.trusted-domain.com") {
    set $valid_host 1;
}
if ($valid_host = 0) {
    return 400;
}