Interpretation Conflict in Rack - #VU159496
Published: November 5, 2026
Vulnerability details
The vulnerability allows a remote attacker to bypass a web application firewall or other inspecting proxy in front of a Rack application by crafting a multipart request that the intermediary interprets differently from Rack. Form fields and file uploads can consequently reach the application without inspection. Rack itself grants no capability beyond that of a well-formed request with the same body.
The vulnerability exists due to incomplete duplicate-boundary detection in Rack::Multipart::Parser.parse_boundary. Its boundary-extraction regular expression uses a lazy prefix and a value class excluding quotes, semicolons, and commas. If the first boundary parameter is empty or begins with one of those characters, the pattern skips it and extracts a later boundary instead. The duplicate check examines only the text after the extracted boundary, leaving the earlier occurrence undetected. A remote attacker can send a crafted multipart request through an inspecting intermediary to a Rack application, causing Rack to accept a later boundary that differs from the intermediary's interpretation.
For example, both multipart/form-data; boundary=";boundary=AaB03x" and multipart/form-data; boundary=; boundary=AaB03x cause Rack to use AaB03x. Under RFC 9110, the quoted example instead contains a single parameter with the value ;boundary=AaB03x, which is not a legal multipart boundary under RFC 2046 and therefore requires rejection. Intermediaries implementing the standard grammar, such as ModSecurity, can see a different boundary or no multipart body at all, creating the interpretation conflict that enables the inspection bypass.