CVE-2026-26962: CRLF Injection in Rack Multipart Parser via Obsolete Line Folding

The rack gem serves as the fundamental web server interface for the vast majority of Ruby web applications and frameworks. Within this ecosystem, the Rack::Multipart::Parser component is responsible for parsing incoming HTTP requests that utilize the multipart/form-data encoding. This component extracts file uploads, form fields, and their associated metadata into accessible Ruby hashes for application consumption.

The vulnerability, designated as CWE-93 (Improper Neutralization of CRLF Sequences), manifests during the processing of obsolete line folding (obs-fold) within multipart part headers. The parser incorrectly handles situations where a single header field spans multiple lines. Instead of stripping the line breaks, the parser retains the carriage return and line feed characters within the resulting strings.

When a downstream application utilizes these unsanitized strings in outbound HTTP headers, it introduces severe security risks. Specifically, if an application reflects a tainted multipart variable, such as a filename, back to the user in a Content-Disposition or similar header, the preserved CRLF characters terminate the current header context. This behavior directly facilitates HTTP Response Splitting attacks.

The fundamental flaw stems from a failure to strictly implement RFC 5322 Section 2.2.3 and RFC 7230 guidelines regarding header folding. These specifications permit HTTP header values to span multiple lines, provided that any continuation line begins with at least one whitespace character, such as a space or horizontal tab. This mechanism is known as obsolete line folding or obs-fold.

A compliant parser is required to perform an "unfolding" operation before presenting the header value to the application. This unfolding process involves identifying the sequence of a carriage return, line feed, and trailing whitespace, and subsequently replacing the entire sequence with a single space character. This ensures that multi-line headers are condensed into a single continuous string devoid of control characters.

The Rack::Multipart::Parser implementation successfully identified the presence of folded lines but completely omitted the required substitution transformation. As a result, the literal \r\n sequence remained embedded within parsed parameter strings, such as the filename attribute within a Content-Disposition header.

The presence of unescaped control characters in memory bypasses standard application-level validation routines. Developers operating under the assumption that Rack provides compliant, sanitized header extractions process these strings directly. The failure to unfold the header effectively shifts the burden of CRLF neutralization from the middleware parser to the individual application developer.

The vulnerability was mitigated in Rack version 3.2.6 through commit d50c4d3dab62fa80b2a276271d0d4fb338cfa7df. The maintainers introduced a specific regular expression pattern designed to accurately locate and neutralize obsolete line folding sequences during the multipart extraction phase.

The patch defines the following regular expression constant:

OBS_UNFOLD = /\r\n([ \t])/

This pattern targets any carriage return and line feed sequence immediately followed by a space or tab. Within the parsing logic, the maintainers implemented a global substitution using the gsub! method against the extracted header components:

content_type.gsub!(OBS_UNFOLD, '\1') if content_type
disposition.gsub!(OBS_UNFOLD, '\1') if disposition

The substitution replaces the matched CRLF and whitespace sequence with only the captured whitespace character (\1). This operation correctly implements the required RFC unfolding logic directly within the state machine before the attributes are populated into the application parameter hash.

This fix is comprehensive as it sanitizes the variables at the boundary layer. By ensuring that content_type and disposition are properly unfolded early in the execution flow, the patch prevents downstream application logic from ever encountering embedded control characters originating from folded multipart headers.

Exploitation requires an attacker to construct a malicious HTTP POST request utilizing the multipart/form-data content type. Within the payload boundaries, the attacker injects the obs-fold syntax into a part header to conceal a CRLF sequence. The attacker typically targets attributes known to be reflected by the application, such as the file upload filename.

The following proof-of-concept demonstrates the required request structure:

POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=AaB03x
 
--AaB03x
Content-Disposition: form-data; name="upload"; filename="test\r\n
\t.txt"
Content-Type: application/octet-stream; name="file.php"
 
<?php eval($_POST['x']); ?>
--AaB03x--

When the vulnerable Rack parser processes this request, the extracted filename string becomes test\r\n\t.txt. The attacker does not require any specialized privileges or authentication to deliver this payload. The attack vector is purely network-based and relies entirely on standard HTTP protocol mechanics.

Successful exploitation is conditional upon the presence of a downstream sink. The vulnerable web application must extract the tainted multipart metadata and explicitly embed it into an outbound HTTP response header. For example, if the application executes res['Content-Disposition'] = "attachment; filename=\"#{params[:file][:filename]}\"", the server will emit a split response stream, terminating the header block prematurely.

The primary consequence of this vulnerability is HTTP Response Splitting. By controlling the structural boundaries of the HTTP response via injected CRLF sequences, an attacker can arbitrarily define new HTTP header fields or manipulate the response body entirely. This grants the attacker significant influence over the transaction perceived by the victim client.

HTTP Response Splitting directly facilitates severe secondary attack vectors. An attacker can execute Cross-Site Scripting (XSS) by injecting an entirely new, attacker-controlled response body containing malicious JavaScript. Furthermore, in environments utilizing intermediate caching proxies or Content Delivery Networks (CDNs), the vulnerability enables Cache Poisoning and Request Smuggling attacks by desynchronizing the request-response queue.

The assigned CVSS v3.1 score is 4.8 (Medium), represented by the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N. The attack complexity is rated as High because the vulnerability cannot be exploited in isolation. The exploitation chain requires the downstream application implementation to blindly reflect the unsanitized multipart variables, thereby serving as the necessary sink for the injected payload.

The definitive remediation for CVE-2026-26962 is upgrading the rack gem to version 3.2.6 or later. This patch applies the correct RFC unfolding logic at the middleware layer, globally resolving the vulnerability for all relying applications. System administrators should audit their dependency trees using bundle audit to identify instances of vulnerable Rack versions.

For environments where immediate patching is unfeasible, developers must manually sanitize any metadata extracted from multipart uploads prior to reflection. When constructing response headers, applications should utilize utilities such as Rack::Utils.escape_path or explicitly strip carriage return and line feed characters from user-controlled input. This defensive programming practice acts as a robust safeguard against injection attacks regardless of the middleware state.

Security teams can deploy Web Application Firewall (WAF) rules as an interim defense-in-depth measure. WAF signatures can be configured to detect and reject multipart requests containing part headers with line breaks followed by whitespace characters. While this may interrupt legitimate but rare usage of obs-fold by specialized clients, it effectively neutralizes the exploitation vector until the underlying software is updated.