CVE-2026-59921: Netty CRLF Injection Vulnerability

CVE-2026-59921 Overview

CVE-2026-59921 is a CRLF injection vulnerability [CWE-93] in Netty, an asynchronous event-driven network application framework widely used in Java-based network services. The flaw affects HttpPostRequestEncoder, which constructs multipart HTTP request bodies by concatenating user-supplied filenames and field names directly into Content-Disposition MIME headers. An attacker who controls the filename value can inject carriage return and line feed (\r\n) sequences to smuggle arbitrary MIME headers into the multipart body. Netty maintainers fixed the issue in versions 4.1.136.Final and 4.2.16.Final.

Critical Impact
Attackers who control filename input can inject arbitrary MIME headers into multipart request bodies, corrupting downstream request parsing and integrity.

Affected Products

Netty versions prior to 4.1.136.Final
Netty versions prior to 4.2.16.Final
Applications using HttpPostRequestEncoder with attacker-influenced filenames or field names

Discovery Timeline

2026-07-28 - CVE-2026-59921 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-59921

Vulnerability Analysis

The vulnerability resides in Netty's HTTP multipart encoder. HttpPostRequestEncoder builds each multipart part by inserting caller-supplied filename and field name strings into the Content-Disposition header. MIME headers use CRLF (\r\n) as delimiters, so any unescaped CRLF in these values ends the current header and begins a new one. The encoder performs no validation of these control characters.

The FileUpload implementations expose a setFilename() method that only rejects null values. It does not strip or reject \r, \n, or the combined \r\n sequence. As a result, filenames flowing from upstream input into outgoing multipart requests can carry embedded headers into the wire format.

Exploitation requires an attacker positioned to supply filename or field name values that a Netty-based client subsequently encodes and transmits. The impact is scoped to integrity of the outbound HTTP request, matching the CVSS integrity-only impact profile.

Root Cause

The root cause is missing neutralization of CRLF characters (\r\n) before embedding user-controlled strings into MIME header fields. Neither HttpPostRequestEncoder nor FileUpload.setFilename() sanitize or reject these delimiters, violating the header construction contract described in CWE-93: Improper Neutralization of CRLF Sequences.

Attack Vector

An attacker supplies a filename containing an embedded CRLF sequence followed by an injected header, for example a crafted Content-Type or a second Content-Disposition. When the Netty client encodes the multipart body, the injected bytes appear as legitimate headers to the receiving server. This can be used to override intended part metadata, confuse multipart parsers, or forge additional part attributes. Refer to the GitHub Security Advisory GHSA-gcjf-9mgh-3p7g for the vendor description.

Detection Methods for CVE-2026-59921

Indicators of Compromise

Multipart request bodies containing filenames with raw \r\n byte sequences
Unexpected duplicate Content-Disposition or Content-Type headers within a single multipart part
Server-side parser errors or anomalous part boundaries in HTTP access logs of applications receiving Netty client traffic

Detection Strategies

Inspect outbound HTTP multipart traffic from Java services for filenames containing CR (0x0D) or LF (0x0A) bytes
Scan dependency manifests (pom.xml, build.gradle) for Netty versions below 4.1.136.Final or 4.2.16.Final
Add runtime assertions or WAF rules that reject multipart filenames containing control characters

Monitoring Recommendations

Log filename values passed to HttpPostRequestEncoder.addBodyFileUpload() and related APIs
Alert on multipart requests where a part contains more than one Content-Disposition header line
Track Netty library versions across application inventory and flag deployments on unpatched releases

How to Mitigate CVE-2026-59921

Immediate Actions Required

Upgrade Netty to 4.1.136.Final on the 4.1.x branch or 4.2.16.Final on the 4.2.x branch
Audit application code paths that pass externally influenced strings into setFilename() or field-name parameters
Add input validation that rejects \r and \n in filenames before invoking the encoder

Patch Information

Netty maintainers fixed the vulnerability in versions 4.1.136.Final and 4.2.16.Final. The patch neutralizes CRLF characters during multipart header construction. Full details are available in the Netty GitHub Security Advisory GHSA-gcjf-9mgh-3p7g.

Workarounds

Sanitize filename inputs at the application layer by stripping or rejecting \r and \n before calling Netty encoder APIs
Wrap HttpPostRequestEncoder usage in a helper that validates filenames against an allowlist pattern
Where feasible, avoid propagating untrusted filenames into outbound multipart requests

bash

# Maven dependency update example
# Update pom.xml to a patched Netty version
<dependency>
  <groupId>io.netty</groupId>
  <artifactId>netty-codec-http</artifactId>
  <version>4.1.136.Final</version>
</dependency>