Rack EUVD-2026-18417

This vulnerability presents moderate real-world risk despite its 4.8 CVSS score. The CVSS vector indicates network-accessible attack surface (AV:N) but high complexity (AC:H), requiring attackers to craft specially-formatted multipart requests with precise obs-fold sequences-this complexity barrier significantly reduces opportunistic exploitation. The unauthenticated scope (PR:N, UI:N) means any remote client can attempt the attack without credentials or user interaction. However, the actual impact depends critically on downstream application behavior: the vulnerability only becomes exploitable if the application (1) parses multipart requests via Rack, (2) extracts the vulnerable parsed values, and (3) uses them directly in HTTP response headers without sanitization. Many applications use these values in form processing or file uploads where they never touch response headers, making exploitation impossible. EPSS data is not provided, but the AC:H vector and contextual dependency suggest lower exploitation probability than the CVSS base score implies. The confidentiality and integrity impacts (C:L, I:L) are conditional on successful header injection exploitation. Per SSVC framework: exploitation status is unconfirmed (no KEV, no POC identified), automatable only if targets are explicitly known to misuse parsed values in responses, and technical impact is partial (response splitting is serious but does not enable full system compromise). This is a legitimate patch-worthy vulnerability but not an emergency-prioritize based on whether your applications actually use multipart parameters in response headers.

An attacker submits a multipart form request with a specially-crafted Content-Disposition header containing an obs-fold sequence (e.g., filename="test.pdf"\r \x20X-Injected-Header: malicious) to a vulnerable Ruby web application. The Rack parser unfolds this header but retains the embedded CRLF, storing the malicious CRLF in the parsed filename parameter. If the application reflects this filename in a response header-for example, via Content-Disposition: attachment; filename=#{uploaded_filename}-the injected CRLF breaks the header boundary, allowing the attacker to inject arbitrary headers (e.g., Set-Cookie, Location) or split the response to inject malicious content into the response body. This could facilitate session hijacking via Set-Cookie injection, cache poisoning in shared proxies, or credential theft via Location header redirection. High request complexity (AC:H) makes opportunistic scanning difficult; exploitation requires knowledge of specific downstream application behavior.