GHSA-gcjf-9mgh-3p7g Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder

• Maven io.netty:netty-codec-http: >= 4.2.0.Final, < 4.2.16.Final → fixed in 4.2.16.Final • Maven io.netty:netty-codec-http: < 4.1.136.Final → fixed in 4.1.136.Final

Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder 1. Vulnerability Summary | Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions with codec-http multipart) | | Component | `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` | | Vulnerability Type | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting | | Impact | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition | | CVSS 3.1 Score | 8.1 (High) | | CVSS 3.1 Vector | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` | | Attack Vector | Network | | Attack Complexity | Low | | Privileges Required | Low (attacker must be able to upload files with controlled filenames) | | User Interaction | None | | Scope | Unchanged | | Confidentiality Impact | High | | Integrity Impact | High | | Availability Impact | None | 2. Affected Components The following classes in the `codec-http` module are affected: • `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` — directly concatenates unvalidated filename/name into `Content-Disposition` MIME headers (lines 519, 633, 674, 682, 686-688) • `io.netty.handler.codec.http.multipart.DiskFileUpload` — `setFilename()` only checks null (line 78) • `io.netty.handler.codec.http.multipart.MemoryFileUpload` — `setFilename()` only checks null (line 60) • `io.netty.handler.codec.http.multipart.MixedFileUpload` — `setFilename()` delegates without validation (line 62) 3. Vulnerability Description Netty's `HttpPostRequestEncoder` constructs multipart HTTP request bodies by directly concatenating user-supplied filenames and field names into `Content-Disposition` MIME headers without validating or sanitizing CRLF characters (`\r\n`). Since MIME headers are delimited by CRLF, an attacker who controls the filename can inject arbitrary MIME headers into the multipart body part. Root Cause In `HttpPostRequestEncoder.java`, multiple code paths directly embed `fileUpload.getFilename()` into header strings: ```java // Line 674 (attachment mode): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.ATTACHMENT + "; " + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION // Lines 686-688 (form-data mode): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; " + HttpHeaderValues.NAME + "=\"" + fileUpload.getName() + "\"; " + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION // Line 519 (attribute name): internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; " + HttpHeaderValues.NAME + "=\"" + attribute.getName() + "\"\r\n"); // ^^^^^^^^^^^^^^^^^ NO VALIDATION ``` The `setFilename()` method in all `FileUpload` implementations only checks for null: ```java // DiskFileUpload.java:77-79 public void setFilename(String filename) { this.filename = ObjectUtil.checkNotNull(filename, "filename"); // NO CRLF VALIDATION } ``` Comparison with Similar Fixed CVEs This vulnerability follows the same pattern as: | CVE | Component | Fix | |-----|-----------|-----| | GHSA-jq43-27x9-3v86 | SmtpRequestEncoder — SMTP command injection | Added CRLF validation in `SmtpUtils.validateSMTPParameters()` | | GHSA-84h7-rjj3-6jx4 | HttpRequestEncoder — CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` | The multipart encoder has no equivalent validation for filenames or field names. 4. Exploitability Prerequisites This vulnerability is exploitable when: 1. The application uses Netty's `HttpPostRequestEncoder` to construct multipart HTTP requests 2. The filename of an uploaded file is derived from user-controlled input 3. The application does not perform its own CRLF sanitization on filenames Common affected patterns: • File upload proxies that forward user-supplied filenames • API gateways that construct multipart requests from incoming parameters • Microservice communication that passes filenames between services • Testing/automation frameworks that use Netty HTTP client with user-defined filenames 5. Attack Scenarios Scenario 1: Content-Type Override via Filename Injection An attacker uploads a file with a crafted filename to override the Content-Type of the multipart body part, potentially enabling stored XSS: ```java String maliciousFilename = "photo.jpg\"\r\nContent-Type: text/html\r\n\r\nalert(document.cookie)\r\n--"; DiskFileUpload upload = new DiskFileUpload( "avatar", maliciousFilename, "image/jpeg", "binary", UTF_8, fileSize); ``` Wire format: ``` --boundary content-disposition: form-data; name="avatar"; filename="photo.jpg" Content-Type: text/html alert(document.cookie) alert(1)\r\n--"; HttpRequest request = new DefaultHttpRequest( HttpVersion.HTTP_1_1, HttpMethod.POST, "/upload"); HttpPostRequestEncoder encoder = new HttpPostRequestEncoder( new DefaultHttpDataFactory(false), request, true, StandardCharsets.UTF_8, HttpPost…