Netty's HttpPostRequestEncoder constructs multipart HTTP request bodies by embedding user-supplied filenames and field names directly into Content-Disposition MIME headers without validating or sanitizing CRLF sequences. The setFilename() methods in related FileUpload classes only check for null values and do not validate or sanitize CRLF characters. This improper neutralization of CRLF sequences (CWE-93) enables HTTP response splitting and MIME header injection, allowing an attacker to inject arbitrary headers or content into multipart body parts. Exploitation requires that the application uses Netty's HttpPostRequestEncoder with user-controlled filenames and does not perform its own CRLF sanitization. Attack scenarios include content-type override and stored XSS via crafted filenames. The vulnerability has a CVSS 3.1 score of 8.1 (High) according to the report, but the provided data lists a moderate severity and a CVSS vector with no confidentiality impact, indicating some discrepancy. No vendor patch or official fix information is provided.

An attacker who can control the filename of an uploaded file can inject CRLF sequences into multipart MIME headers, leading to MIME header injection, content-type spoofing, and potentially stored cross-site scripting (XSS) attacks. This compromises confidentiality and integrity of the affected application’s HTTP multipart requests. The vulnerability does not impact availability. Exploitation requires low privileges and no user interaction.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, applications using Netty's HttpPostRequestEncoder should implement their own validation and sanitization of filenames and field names to remove or encode CRLF characters before passing them to the encoder. Avoid using user-controlled input directly in multipart headers without sanitization.