CVE-2026-34835

What it actually does

Rack::Request incorrectly accepts non-RFC hostname characters in the HTTP Host authority parsing logic for affected Rack 3.x versions. Specifically, Host values containing characters such as '/', '?', '#', and '@' can be treated as part of req.host rather than rejected or normalized safely. Applications that rely on Rack-provided req.host, req.url, or req.base_url for host authorization, redirect construction, password reset links, canonical URL generation, tenant routing, or origin validation may be vulnerable if they use weak prefix/suffix allowlist checks. The direct impact is host header poisoning and validation bypass; exploitation generally requires an application-specific unsafe trust decision based on the parsed host value, which is why the CVSS attack complexity is high.

Why it matters to the business

An affected Ruby application may generate links, redirects, or security decisions using an attacker-controlled host value. In practical terms, this can enable phishing through trusted application-generated links, redirect abuse, cache or proxy confusion, incorrect origin validation, or bypass of host allowlists in applications that perform naive string matching. The issue is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and has no public exploit maturity reported, but Rack is a foundational dependency in many Ruby web stacks, so exposure can be widespread through frameworks and downstream packages.

How an attack unfolds

An attacker sends an HTTP request to a Rack-based application with a crafted Host header containing characters that are not valid in a hostname but are accepted by vulnerable Rack parsing. If the application reads req.host, req.url, or req.base_url and then performs an unsafe prefix or suffix check, the crafted value may appear to satisfy the allowlist while still embedding attacker-controlled authority-like content. The application may then use that poisoned value to generate absolute links, issue redirects, validate an origin, construct password reset or invitation URLs, or make routing/security decisions. Successful exploitation depends on the application trusting the Rack-parsed host value without strict hostname validation and on the presence of a code path where the poisoned host influences security-sensitive behavior.

How to fix it

Upgrade Rack to a patched version: 3.1.21 or later on the 3.1.x line, or 3.2.6 or later on the 3.2.x line. If dependency resolution is managed through Bundler, update the Gemfile/Gemfile.lock and rebuild/redeploy affected applications. If an immediate upgrade is not possible, mitigate by enforcing strict host validation at the edge and in the application: reject Host and X-Forwarded-Host values containing invalid hostname characters such as '/', '?', '#', '@', backslashes, whitespace, or control characters; use exact hostname allowlists rather than prefix/suffix checks; avoid using untrusted request host values to generate sensitive links; and configure framework-level trusted host middleware where available. Review application code for unsafe uses of req.host, req.url, and req.base_url in redirects, link generation, origin checks, tenant selection, and authentication workflows.

How to confirm the fix worked

Confirm that runtime dependency inventories, lockfiles, container images, and deployed artifacts no longer include affected Rack versions. For Bundler-based applications, verify with commands such as `bundle info rack`, `bundle list | grep rack`, or inspection of Gemfile.lock to ensure Rack is 3.1.21 or later on the 3.1 branch or 3.2.6 or later on the 3.2 branch. Perform negative testing against non-production instances by sending Host headers containing '/', '?', '#', and '@' and verifying the application rejects them, normalizes them safely, or does not use them in generated links, redirects, or security decisions. Review proxy, load balancer, CDN, and application logs to ensure invalid Host values are rejected before reaching the application. Validate that host allowlists use exact canonical hostname comparison and not naive string prefix/suffix logic.

Typical attack path

1. Identify a Ruby/Rack application running an affected Rack version: 3.0.0.beta1 through versions before 3.1.21, or 3.2.0 through versions before 3.2.6.
2. Send requests with crafted Host headers containing characters such as '/', '?', '#', or '@'.
3. Observe whether the application reflects or uses the supplied host in redirects, generated links, password reset flows, invitation links, canonical URLs, CORS/origin checks, or tenant routing.
4. Tune the Host value to bypass naive allowlist logic such as starts-with or ends-with checks.
5. Trigger a user-facing or security-sensitive workflow that uses req.host, req.url, or req.base_url.
6. Abuse the poisoned host result for phishing, redirect manipulation, origin validation bypass, or application-specific trust confusion.

How to detect it

To determine whether exploitation was attempted or successful, review web server, reverse proxy, CDN/WAF, load balancer, and application logs for requests where the Host or X-Forwarded-Host header contains characters that should not appear in a normal hostname, especially '/', '?', '#', and '@'. Focus on endpoints that generate absolute URLs, perform redirects, send email links, handle login, password reset, invitation, account verification, OAuth/OIDC callbacks, CORS/origin checks, or tenant routing. Correlate suspicious Host values with 3xx responses, email-sending events, account recovery events, invitation creation, authentication errors, or unusual outbound links. In application logs, search for reflected req.host, req.url, or req.base_url values containing malformed authorities. Also review WAF/proxy rejection logs for blocked invalid Host headers to assess scanning activity. There are no known named threat actors or ransomware campaigns associated with this issue in the provided intelligence.

• Host: .*[@/?#]
• X-Forwarded-Host: .*[@/?#]
• Forwarded: .*host=.*[@/?#]
• HTTP_HOST=.*[@/?#]
• rack.input
• req.host
• req.url
• req.base_url
• ActionController::Redirecting
• Location: http://.*@
• Location: https://.*@
• Location: http://.*/
• Location: https://.*/

What your security team should do

• Inventory Ruby applications and services that include Rack, including transitive dependencies introduced by web frameworks.
• Prioritize upgrades for internet-facing applications, authentication flows, password reset flows, invitation workflows, redirect endpoints, multi-tenant routing, and services using req.host, req.url, or req.base_url.
• Upgrade Rack to 3.1.21 or later, or 3.2.6 or later, and redeploy affected applications.
• Add edge-layer filtering to reject Host and X-Forwarded-Host values containing invalid hostname characters, especially '/', '?', '#', and '@'.
• Audit application code for host allowlist checks based on starts-with, ends-with, substring, or regular expressions that do not strictly validate canonical hostnames.
• Harden link and redirect generation by using configured canonical hostnames instead of request-supplied host headers for security-sensitive workflows.
• Create SIEM detections for suspicious Host or X-Forwarded-Host values containing invalid hostname delimiters and correlate them with redirects, account recovery, invitation, login, and origin-validation endpoints.
• Because EPSS is very low, no KEV listing exists, and no exploit maturity is reported, treat this as a broad hygiene and exposure-reduction item unless affected applications perform sensitive host-based trust decisions.