Rack EUVD-2026-18478

The CVSS 3.1 score of 4.8 with vector AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N reflects a network-accessible vulnerability requiring high attack complexity, with low impact on confidentiality and integrity but no availability impact. The high attack complexity (AC:H) suggests the exploit requires specific application behavior (naive host validation logic) that must be present in the target application. No EPSS score or POC availability is provided in the input data, and no active exploitation (KEV status) is confirmed. From an SSVC perspective, this is not easily automatable across arbitrary Rack deployments-only applications using req.host for validation without strict RFC compliance checking are vulnerable. Real-world risk depends heavily on the target application's host validation implementation; well-designed applications using allowlist-based validation or strict RFC parsing are unaffected. This is a moderate-priority issue driven by the prevalence of Rack in Ruby web frameworks, but the high attack complexity and lack of confirmed active exploitation reduce the immediate urgency compared to high-CVSS critical vulnerabilities.

An attacker sends an HTTP request with a malicious Host header such as 'trusted.example.com@attacker.com/?...' targeting an application that uses Rack and performs host validation by checking if req.host starts with or ends with 'example.com'. The AUTHORITY regex in Rack 3.2.5 or earlier parses and accepts the malformed host value. If the application then uses req.host in a redirect, email link, or origin validation check, the attacker can trick users into visiting attacker-controlled domains or bypass origin restrictions. For example, a password reset link generated using req.host might redirect to attacker.com while appearing to come from the legitimate domain. High attack complexity reflects the requirement that the target application must use naive host validation; applications with strict RFC-compliant parsing or allowlist validation are not affected.