CVE-2026-93574: Io.netty/netty-codec-http: netty: http request smuggling via post-digit whitespace in chunk-size parsing
A flaw was found in Netty's netty-codec-http component. A remote attacker could exploit this vulnerability by sending a specially crafted HTTP/1.1 chunk-size token that includes post-digit whitespace. This incorrect parsing of the chunk size can lead to HTTP request smuggling. This allows an attacker to bypass security controls or access unauthorized resources in proxy/backend deployments.
Other sources
HTTP request smuggling via post-digit whitespace in chunk-size parsing
A public GitHub Security Advisory (GHSA-j4mg-hqgv-34qc) describes the following issue:
Summary
io.netty:netty-codec-http accepts post-digit whitespace inside an HTTP/1.1 chunk-size token, truncates parsing at that whitespace/control byte, and does not validate the remaining bytes on the line. A malformed chunk line such as 5 c\r\n is parsed as size 0x5 instead of being rejected. The attached local PoV shows Netty then parsing GET /smuggled as a second request on the same connection.
PoC
Run:
sh bash poc/reproduce.sh
The important case is:
text POST / HTTP/1.1\r\n Host: example\r\n Transfer-Encoding: chunked\r\n \r\n 5 c\r\n GPOST\r\n 0\r\n \r\n GET /smuggled HTTP/1.1\r\n Host: example\r\n \r\n
Expected output:
text CASE internal-space-smuggle-shape httpContent class=DefaultHttpContent bytes=5 text=GPOST decoderSuccess=true lastContent=true httpRequest uri=/smuggled path=/smuggled decoderSuccess=true
The PoV also includes:
- 5 x, showing that arbitrary suffix bytes after post-digit whitespace are ignored for sizing. - 5 c;foo=bar, showing that the ambiguity survives when chunk-extension validation is invoked.
Impact
This is an HTTP request-smuggling primitive in proxy/backend deployments where another HTTP component interprets the same malformed chunk-size line differently. Netty is the component that accepts the malformed chunked body and splits the stream into two requests.
No live services were probed. The PoV uses only EmbeddedChannel and HttpRequestDecoder.
This report is not about leading/trailing whitespace compatibility around a chunk-size line. It targets post-digit internal whitespace followed by additional token bytes.
Suggested Fix
Reject internal whitespace/control characters in the chunk-size token. If Netty wants to preserve compatibility for leading/trailing SP/HTAB, the parser should transition to a trailing-whitespace state after the first post-digit whitespace byte and reject any later hex digit or token byte before ;/CRLF.
Affected Package/Versions
Verified affected:
- 4.2.15.Final - 4.2.14.Final - 4.2.13.Final - 4.1.135.Final - 4.1.133.Final - 4.1.90.Final - 4.1.87.Final - current 4.2 branch at 7bae566a93e69409697fe57fa807910ba5c9720e
Verified not affected by this exact PoV:
- 4.1.89.Final - 4.1.88.Final
References
- Netty security policy: https://github.com/netty/netty/security/policy - RFC 9112 chunked transfer coding: https://www.rfc-editor.org/rfc/rfc9112#name-chunked-transfer-coding - Netty HttpDecoderConfig framing-validation documentation: https://netty.io/4.2/api/io/netty/handler/codec/http/HttpDecoderConfig.html - Adjacent Netty chunk-size advisory: https://github.com/netty/netty/security/advisories/GHSA-m4cv-j2px-7723 - Adjacent Netty initial-control-character advisory: https://github.com/netty/netty/security/advisories/GHSA-hvcg-qmg6-jm4c - Adjacent Netty start-line injection advisory: https://github.com/advisories/GHSA-v8h7-rr48-vmmv - CWE-444: https://cwe.mitre.org/data/definitions/444.html
Classification
- CWE-444 - Suggested severity: Moderate - Suggested CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
Non-Duplicate Boundary
This is distinct from prior Netty request-smuggling advisories:
- GHSA-m4cv-j2px-7723 fixed chunk-size integer overflow in getChunkSize; this candidate reproduces on its patched versions 4.2.13.Final and 4.1.133.Final. - GHSA-hvcg-qmg6-jm4c / CVE-2026-50020 fixed non-CRLF control-character skipping before the request line; this candidate is in chunk-size parsing after a normal POST request has already started, and it reproduces on that advisory's patched versions 4.2.15.Final and 4.1.135.Final. - GHSA-v8h7-rr48-vmmv / CVE-2026-41417 fixed setUri() start-line injection during outbound encoding; this candidate is inbound chunk-size parsing and does not require DefaultHttpRequest.setUri(). - GHSA-fghv-69vj-qj49 and GHSA-pwqr-wmgm-9rr8 concern chunk-extension parsing; this candidate is in the chunk-size token before extension parsing. - GHSA-38f8-5428-x5cv concerns malformed Transfer-Encoding; this candidate uses a normal Transfer-Encoding: chunked header and a malformed chunk-size line.
Affected: - maven:io.netty:netty-codec-http affected >=4.2.13.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-http affected >=4.1.90.Final, <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-j4mg-hqgv-34qc
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.2.17.Final - Upgrade
Upgrade
io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.1.137.Final
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs network access to send a specially crafted HTTP/1.1 request using Transfer-Encoding: chunked. No privileges or user interaction are required according to the supplied severity vector.
Which deployments are most relevant for triage?
Proxy and backend deployments are the key concern, because inconsistent request interpretation can enable request smuggling. The issue affects use of Netty's io.netty:netty-codec-http component when processing malformed chunk-size lines containing whitespace or control bytes after the size digits.