Описание
Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
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 intoContent-DispositionMIME 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:
The setFilename() method in all FileUpload implementations only checks for null:
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:
- The application uses Netty's
HttpPostRequestEncoderto construct multipart HTTP requests - The filename of an uploaded file is derived from user-controlled input
- 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:
Wire format:
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
Injects arbitrary headers into the multipart body part that may be processed by downstream middleware or application logic.
Scenario 3: Multipart Boundary Confusion
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)
How to Compile and Run
PoC Execution Output (Verified on Netty 4.2.12.Final)
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)
Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)
Escape or reject CRLF characters when building Content-Disposition headers:
Option 3: RFC 2231/5987 Encoding for Filenames
Use proper RFC 2231 encoding for filenames with special characters:
9. References
- RFC 2183: Content-Disposition Header Field
- RFC 7578: Returning Values from Forms: multipart/form-data
- RFC 5987: Character Set and Language Encoding for HTTP Header Field Parameters
- CWE-93: Improper Neutralization of CRLF Sequences
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers
- GHSA-jq43-27x9-3v86: Netty SMTP Command Injection (same pattern)
- GHSA-84h7-rjj3-6jx4: Netty HTTP CRLF Injection (same pattern)
Пакеты
io.netty:netty-codec-http
>= 4.2.0.Final, < 4.2.16.Final
4.2.16.Final
io.netty:netty-codec-http
< 4.1.136.Final
4.1.136.Final
Связанные уязвимости
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, 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. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
A flaw was found in Netty's HttpPostRequestEncoder, a widely used Java networking library component responsible for constructing multipart HTTP request bodies. The issue arises because user-supplied filenames and field names are directly embedded into Content-Disposition MIME headers without any validation or sanitization of CRLF (\r\n) characters. Since MIME headers are delimited by CRLF sequences, an attacker who controls the filename in a multipart upload can inject arbitrary MIME headers into the request body. This may lead to limited Content-Type spoofing or header manipulation against middleware or storage layers processing the request, though the practical impact is constrained by the context in which Netty is deployed.
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, 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. The root cause is that neither the encoder nor the FileUpload implementations' setFilename() methods, which only check for null, neutralize CRLF characters before the filename is embedded into the header. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
Netty is an asynchronous, event-driven network application framework. ...