CVE-2026-59921

What it actually does

CVE-2026-59921 is an improper input validation flaw in Netty's multipart HTTP request construction. Before Netty 4.1.136.Final and 4.2.16.Final, HttpPostRequestEncoder inserts user-controlled multipart field names and filenames directly into Content-Disposition MIME headers without neutralizing carriage-return/line-feed characters. An attacker who can influence a filename or field name used by an application when generating multipart requests can inject additional MIME headers into a multipart body part. The primary technical consequence is integrity impact: downstream systems that parse the generated multipart request may interpret attacker-supplied injected headers as legitimate part metadata.

Why it matters to the business

Applications using affected Netty versions to generate multipart HTTP requests may send malformed or attacker-influenced requests to downstream services, APIs, upload processors, or integrations. This can result in incorrect file metadata, bypassed validation logic, unexpected handling by receiving services, or corruption of business workflows that rely on multipart upload integrity. The CVSS score is moderate and EPSS is currently low, and the vulnerability is not listed in CISA KEV, but organizations with upload forwarding, API gateway, proxy, or service-to-service multipart generation patterns should prioritize patching because exploitation can affect data integrity across integrated systems.

How an attack unfolds

An attacker first needs a path to supply or influence a filename or multipart field name that an application later passes into Netty's HttpPostRequestEncoder. Instead of using a normal filename, the attacker includes CRLF sequences followed by attacker-chosen MIME header text. When the affected Netty encoder builds the multipart request body, it concatenates the unsanitized value into the Content-Disposition header. The CRLF characters terminate the intended header line and cause the attacker-controlled text to be interpreted as additional MIME headers inside that multipart part. The receiving service then parses the generated multipart request and may process the injected headers as if they were legitimately produced by the application. Exploitation depends heavily on application behavior and downstream parser behavior; this is not a general remote code execution issue, but it can undermine validation, routing, or metadata decisions that trust multipart headers.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later on the 4.1.x line, or 4.2.16.Final or later on the 4.2.x line. Because Netty is commonly pulled in transitively by frameworks and SDKs, review dependency trees and software composition analysis results for indirect exposure. If immediate upgrade is not possible, add defensive validation before values are passed to multipart encoders: reject or normalize carriage return and line feed characters in filenames and multipart field names, and ensure upload metadata is canonicalized before use. Do not rely only on downstream parsers to reject malformed multipart content. Rebuild and redeploy affected services after dependency updates.

How to confirm the fix worked

Confirm that dependency resolution selects Netty 4.1.136.Final or later, or 4.2.16.Final or later, for all deployed artifacts. Use build tooling such as Maven dependency:tree, Gradle dependencies, SBOM analysis, container image scanning, and runtime classpath inspection to detect older io.netty components. Validate behavior with a regression test that attempts to create a multipart request using a filename containing CRLF characters, such as a value containing '\r\nX-Test: injected', and confirm the generated multipart body does not contain an injected MIME header. Also verify that application-level input validation rejects filenames and multipart field names containing CR or LF characters.

Typical attack path

1. Identify an application or service that uses Netty to construct outbound multipart HTTP requests.
2. Find an input point where the attacker can control or influence a multipart filename or field name.
3. Submit a filename or field name containing CRLF characters followed by crafted MIME header content.
4. Allow the application to construct a multipart request using the vulnerable Netty HttpPostRequestEncoder.
5. The vulnerable encoder embeds the unsanitized value into the Content-Disposition header.
6. A downstream multipart parser interprets the injected text as additional MIME headers.
7. The attacker leverages the altered multipart metadata to influence processing, validation, or business logic.

How to detect it

To assess prior exploitation, review application access logs, upload audit logs, API gateway logs, reverse proxy logs, and downstream multipart consumer logs for filenames or field names containing literal CRLF characters, percent-encoded CRLF sequences, or MIME header-like strings embedded inside filename parameters. Focus on requests that resulted in uploads, file forwarding, or service-to-service multipart submissions from applications using affected Netty versions. Inspect downstream service logs for unexpected multipart part headers, duplicate Content-Type or Content-Disposition values, unusual Content-Transfer-Encoding headers, or metadata fields that do not match application-generated values. If raw HTTP request or response capture is available, search multipart bodies for Content-Disposition filename values followed by additional header lines before the blank line that separates headers from content. Because exploitation artifacts are application-specific and may not produce errors, detection should combine dependency exposure, suspicious input patterns, and downstream metadata anomalies.

• %0d%0aContent-Type:
• %0D%0AContent-Type:
• %0d%0aContent-Disposition:
• %0D%0AContent-Disposition:
• %0d%0aContent-Transfer-Encoding:
• %0D%0AContent-Transfer-Encoding:
• \r\nContent-Type:
• \r\nContent-Disposition:
• \r\nContent-Transfer-Encoding:
• filename*=*%0d%0a
• filename*=*%0D%0A
• filename="*\r\n
• name="*\r\n
• Content-Disposition: form-data; name="*"; filename="*\r\n
• X-Test: injected

What your security team should do

• Inventory applications, services, SDKs, and containers that include Netty, including transitive dependencies.
• Prioritize externally reachable upload, file-forwarding, proxy, API integration, and service-to-service multipart generation components.
• Upgrade to Netty 4.1.136.Final or later, or 4.2.16.Final or later, and redeploy affected workloads.
• Add application-layer validation to reject CRLF characters in filenames and multipart field names, even after upgrading.
• Search logs for suspicious filenames or multipart field names containing encoded or literal CRLF sequences followed by MIME-like header names.
• Review downstream services that consume multipart requests from affected applications for evidence of anomalous part headers or unexpected upload metadata.
• Add regression tests covering CRLF injection in multipart filenames and field names to prevent reintroduction.
• Monitor vendor advisories and dependency management systems for downstream framework releases that bundle fixed Netty versions.