CVE-2026-59921: 
Java 취약성 분석 및 완화

CVE-2026-59921 is a CRLF injection vulnerability in Netty's HttpPostRequestEncoder component that allows authenticated attackers to inject arbitrary MIME headers into multipart HTTP request bodies by supplying crafted filenames containing \r\n sequences. It affects io.netty:netty-codec-http versions up to and including 4.2.15.Final and 4.1.135.Final. The vulnerability was published by Netty maintainer normanmaurer on July 14, 2026, and added to the GitHub Advisory Database on July 22, 2026. The official GitHub Advisory assigns a CVSS v3.1 score of 5.7 (Moderate) with an adjacent-network attack vector, while the advisory description also references a researcher-calculated score of 8.1 (High) under a network attack vector (GitHub Advisory, Netty Security Advisory).

The root cause is CWE-93 (Improper Neutralization of CRLF Sequences): HttpPostRequestEncoder.java directly concatenates user-supplied filenames and field names into Content-Disposition MIME headers at lines 519, 633, 674, and 686–688 without any CRLF validation. The setFilename() methods in DiskFileUpload, MemoryFileUpload, and MixedFileUpload only check for null, performing no sanitization. Because MIME headers are delimited by \r\n, an attacker who controls the filename parameter can terminate the current header value and inject new headers (e.g., Content-Type: text/html) or even new multipart body parts. Exploitation requires low privileges — specifically, the ability to supply a filename that is passed to HttpPostRequestEncoder without prior sanitization by the application. A public proof-of-concept (MultipartFilenameInjectionPoC.java) has been published and verified against Netty 4.2.12.Final (GitHub Advisory, Netty Security Advisory).

Successful exploitation enables MIME header injection into multipart request bodies, with three primary consequences: (1) Content-Type spoofing — overriding application/octet-stream with text/html to cause uploaded files to be served as HTML, enabling stored XSS; (2) arbitrary MIME header injection — inserting custom headers (e.g., X-Bypass-Check: true) that may be processed by downstream middleware, CDNs, or storage layers; and (3) multipart boundary confusion — injecting new boundary delimiters to create or override form fields processed by the server. Confidentiality impact is assessed as None by the official advisory (no direct data leakage), while integrity impact is High due to content manipulation and potential XSS. Availability is unaffected (GitHub Advisory).

1. Identify a vulnerable target: Locate an application that uses Netty's HttpPostRequestEncoder to construct multipart HTTP requests and passes user-controlled filenames to DiskFileUpload, MemoryFileUpload, or MixedFileUpload without prior CRLF sanitization (e.g., file upload proxies, API gateways, microservices).
2. Craft a malicious filename: Construct a filename containing embedded CRLF sequences to inject additional MIME headers. Example payload:

   innocent.txt"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n<script>alert(document.cookie)</script>\r\n--

3. Submit the file upload request: Send a multipart POST request to the target endpoint with the crafted filename. The Netty encoder will embed the filename directly into the Content-Disposition header without validation.
4. Observe injected headers in the wire format: The encoded multipart body will contain the injected Content-Type: text/html and X-Injected: true headers as separate MIME headers within the body part, overriding the original content type.
5. Achieve the attack objective: If the receiving server or downstream system serves the uploaded file back to users, the Content-Type: text/html override causes the file to be rendered as HTML, executing the injected XSS payload. Alternatively, injected custom headers may bypass middleware access controls or manipulate downstream processing logic (GitHub Advisory, Netty Security Advisory).

• Network: Multipart POST requests where the Content-Disposition header's filename parameter contains literal \r\n sequences, percent-encoded CRLF (%0D%0A), or embedded header-like strings (e.g., Content-Type:, X- prefixes) within the filename value.
• Logs: Application or proxy logs showing filenames with unusual characters such as carriage returns, newlines, or embedded header names; HTTP access logs recording POST requests to file upload endpoints with abnormally long or malformed Content-Disposition values.
• File System: Uploaded files stored with filenames containing CRLF characters or truncated at a quote character, indicating the server received an injected filename.
• Application Behavior: Unexpected Content-Type values (e.g., text/html) associated with files that should be binary types (e.g., images, PDFs); downstream middleware or CDN logs showing unexpected custom headers (e.g., X-Bypass-Check, X-Custom-Auth) originating from multipart body parts (GitHub Advisory).

Upgrade to the patched versions: Netty 4.2.16.Final or Netty 4.1.136.Final, which include fixes for this vulnerability (Netty 4.2.16.Final Release, Netty 4.1.136.Final Release). If immediate upgrade is not possible, applications should sanitize filenames before passing them to HttpPostRequestEncoder by rejecting or stripping any \r or \n characters. As a defense-in-depth measure, API gateways or reverse proxies in front of Netty-based services should validate and sanitize Content-Disposition filename parameters in incoming requests before forwarding them.

The advisory was published by Netty core maintainer normanmaurer on July 14, 2026, and reviewed and published to the GitHub Advisory Database on July 22, 2026. Tenable added a cloud security plugin (ID 445169) for this vulnerability shortly after the advisory was published. No significant broader media coverage or notable independent researcher commentary has been identified beyond the official advisory and vendor release notes (GitHub Advisory).