CVE-2026-34835: 
Ruby vulnerability analysis and mitigation

CVE-2026-34835 is a host header poisoning vulnerability in Rack, the modular Ruby web server interface, caused by improper validation of the Host header's syntactic correctness. Rack::Request parses the Host header using an AUTHORITY regular expression that accepts RFC-noncompliant characters — including /, ?, #, and @ — allowing attackers to bypass naive prefix or suffix host allowlist checks. Affected versions are 3.0.0.beta1 through before 3.1.21, and 3.2.0 through before 3.2.6. The vulnerability was published on April 1–2, 2026, with patches released the same day. It carries a CVSS v3.1 base score of 4.8 (Moderate) per the GitHub Advisory, with an alternative score of 6.5 (Medium) per NVD (GitHub Advisory, Rack Advisory).

The root cause is classified as CWE-1286 (Improper Validation of Syntactic Correctness of Input). Rack's AUTHORITY regular expression uses a character class ([[:graph:] && [^\[\]]]) that accepts nearly all printable characters except [ and ], including URI-reserved delimiters like @, /, ?, and # that are not valid per RFC 3986 hostname syntax. This means a Host header value such as myapp.com@evil.com passes a req.host.start_with?("myapp.com") check, and evil.com/myapp.com passes a req.host.end_with?("myapp.com") check — both returning attacker-controlled values through req.host, req.url, or req.base_url. No authentication or special privileges are required; the attacker only needs to send a crafted HTTP request with a malformed Host header to a vulnerable application (GitHub Advisory, Rack Advisory).

Successful exploitation enables host header poisoning, which can facilitate password reset link poisoning, open redirects, cache poisoning, phishing, and bypass of origin-dependent security decisions in applications that use req.host, req.url, or req.base_url for link generation or validation. The confidentiality and integrity impacts are low — there is no availability impact — and the scope is unchanged, meaning exploitation is limited to the affected application's trust boundary. The practical severity is highly dependent on application behavior; if a reverse proxy or load balancer already enforces strict Host header validation, exploitability is significantly reduced or eliminated (Rack Advisory, GitHub Advisory).

The GitHub Advisory references a proof-of-concept (advisory-level) available in the official Rack security advisory, but no runnable exploit code or step-by-step exploitation instructions have been published. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.131% (32nd percentile), indicating a low near-term exploitation probability (GitHub Advisory, Rack Advisory).

1. Reconnaissance: Identify Ruby web applications using Rack versions 3.0.0.beta1–3.1.20 or 3.2.0–3.2.5 that perform host validation using req.host, req.url, or req.base_url with naive prefix/suffix string checks (e.g., start_with? or end_with?).
2. Craft malicious Host header: Construct an HTTP request with a Host header containing RFC-noncompliant characters to bypass the target's allowlist logic. For example:
   • To bypass req.host.start_with?("myapp.com"): set Host: myapp.com@evil.com
   • To bypass req.host.end_with?("myapp.com"): set Host: evil.com/myapp.com
3. Send the crafted request: Deliver the HTTP request directly to the application (e.g., via curl -H 'Host: myapp.com@evil.com' https://target-app/reset-password).
4. Trigger host-dependent functionality: Target endpoints that generate absolute URLs, password reset links, redirects, or perform origin validation — causing the application to embed the attacker-controlled host value in responses or emails.
5. Achieve objective: Depending on application behavior, harvest credentials via poisoned password reset links, redirect users to attacker-controlled sites, or poison shared caches with malicious responses (Rack Advisory, GitHub Advisory).

• Network: Inbound HTTP requests containing Host headers with RFC-noncompliant characters such as @, /, ?, or # (e.g., Host: myapp.com@evil.com, Host: evil.com/myapp.com, Host: evil.com#myapp.com).
• Logs: Web server or application access logs showing requests with anomalous Host header values that do not conform to standard hostname syntax; look for @, /, ?, or # characters within the Host field.
• Application Behavior: Password reset emails or generated links containing unexpected or attacker-controlled domain names; redirects to external or unexpected hosts originating from the application.
• Reverse Proxy Logs: Requests forwarded to the application backend with non-standard Host headers that were not filtered or rejected by the proxy layer (Rack Advisory).

Upgrade Rack to version 3.1.21 or later (for the 3.1.x branch) or 3.2.6 or later (for the 3.2.x branch), which reject invalid authority characters in the Host header. As a defense-in-depth measure, enforce strict Host header validation at the reverse proxy or load balancer to reject headers containing unexpected characters before they reach the application. Applications should also replace naive start_with?/end_with? host checks with exact allowlist comparisons or proper subdomain boundary validation after confirming syntactic validity. IBM has also released patches for affected downstream products including Aspera Faspex, Aspera Enterprise WebApps, Aspera Shares, and API Connect (Rack Advisory, IBM Aspera Faspex, IBM Aspera Shares).

The vulnerability was coordinated and published by Rack maintainer ioquatix, with th4s1s credited as the reporter and jeremyevans as the remediation developer. Ubuntu issued security notice USN-8182-1 addressing this and related Rack vulnerabilities. IBM published multiple security bulletins covering affected downstream products. No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified (Rack Advisory, Ubuntu Advisory).