CVE-2026-59921

If you're using Netty's HttpPostRequestEncoder, check your setFilename() calls immediately. The method performs a null check only — it does not sanitize CRLF characters from filename input before embedding them into MIME multipart headers. This creates a CRLF injection vulnerability where an attacker controlling the filename parameter can inject arbitrary MIME headers or split responses. The critical insight here is that setFilename() presents itself as a safe operation. It accepts your string without complaint, which lulls developers into believing the framework handles the encoding. It doesn't. The method is a thin wrapper around string concatenation into a protocol boundary that demands CRLF sanitization at that exact point — but the API never signals this requirement. That's the semantic trap: the abstraction makes the common case (normal filenames) work effortlessly while making the secure case invisible. Your action items: First, audit all code paths that pass user-controlled filenames to HttpPostRequestEncoder.setFilename(). Treat any untrusted input as potentially containing CRLF sequences. Second, apply CRLF stripping before calling setFilename() — remove or reject any \r or \n characters in filenames originating from external sources. Third, verify your Netty version: the fix landed in 4.1.136.Final and 4.2.16.Final, so upgrade if you're below those versions. Fourth, audit other Netty APIs that accept string input for protocol construction — this is a recurring pattern in the library where user input flows into HTTP header construction without boundary sanitization at the framework level. The same vigilance you apply to this vulnerability should extend to any place you're constructing headers, cookies, or MIME parts from user data.

Reviewed through automated stages and approved by a human before publication.