CVE-2026-93574 Overview
CVE-2026-93574 is an HTTP request smuggling vulnerability in the netty-codec-http component of the Netty framework. The flaw stems from incorrect parsing of HTTP/1.1 chunk-size tokens that contain post-digit whitespace. A remote attacker can send a specially crafted chunked request to desynchronize front-end proxies from back-end servers. This desynchronization enables security control bypass and unauthorized access to backend resources in proxy/backend deployments. The weakness is classified as [CWE-444] Inconsistent Interpretation of HTTP Requests (HTTP Request Smuggling). Red Hat has issued advisories RHSA-2026:69440 and RHSA-2026:69470 addressing the issue in affected products.
Critical Impact
Attackers can smuggle HTTP requests through Netty-based proxies and backends, bypassing security controls and reaching resources that should be restricted.
Affected Products
- Netty netty-codec-http component (HTTP/1.1 chunked transfer decoder)
- Red Hat products covered by advisory RHSA-2026:69440
- Red Hat products covered by advisory RHSA-2026:69470
Discovery Timeline
- 2026-09-18 - CVE-2026-93574 published to the National Vulnerability Database
- 2026-09-24 - Last updated in NVD database
Technical Details for CVE-2026-93574
Vulnerability Analysis
The vulnerability resides in Netty's HTTP/1.1 chunked transfer encoding decoder within netty-codec-http. When parsing the chunk-size line, the decoder incorrectly accepts whitespace after the hexadecimal size digits but before the terminating CRLF. Different HTTP intermediaries interpret this malformed token in conflicting ways. A front-end proxy may treat the request as valid and forward it to a Netty backend, while the backend parses the message boundary differently. This mismatch allows an attacker to prepend or append arbitrary requests into the connection stream shared by other users.
Attackers use the smuggled request to bypass authentication, access control, and web application firewall rules enforced at the proxy layer. The technique also enables cache poisoning and session hijacking in shared connection pools.
Root Cause
The root cause is lenient parsing of the chunk-size token in violation of RFC 7230. The specification requires the chunk size to be immediately followed by an optional chunk-ext or CRLF, with no permitted whitespace between the size digits and these tokens. Netty's decoder tolerated trailing whitespace after the digits, producing an inconsistent interpretation across HTTP hops.
Attack Vector
Exploitation is remote and unauthenticated. The attacker sends a crafted HTTP/1.1 request over an existing keep-alive connection to a proxy that fronts a Netty-based service. The chunk-size line contains hexadecimal digits followed by whitespace characters before the CRLF. The proxy computes one message length while Netty computes another, splitting a single TCP stream into two differently framed request sequences. See the Red Hat CVE Analysis for CVE-2026-93574 and Red Hat Bug Report #2536966 for further technical detail.
Detect Identity Attacks the Moment Authentication Fails
Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.
Stop Identity AttacksDetection Methods for CVE-2026-93574
Indicators of Compromise
- HTTP/1.1 requests where the chunk-size line contains trailing spaces or tabs before CRLF, for example 1a \r\n instead of 1a\r\n.
- Reverse proxy access logs recording a single client request that correlates with multiple backend requests from the same connection.
- Unexpected Transfer-Encoding: chunked requests targeting endpoints that normally receive Content-Length traffic.
Detection Strategies
- Inspect HTTP traffic at the proxy for chunk-size tokens containing whitespace between digits and CRLF using strict RFC 7230 validation.
- Correlate front-end and back-end request logs by connection identifier to surface framing mismatches indicative of smuggling.
- Deploy WAF signatures that flag malformed chunked encoding and reject requests with ambiguous message length semantics.
Monitoring Recommendations
- Enable verbose request logging on Netty-based services and reverse proxies, including raw chunk headers where feasible.
- Alert on sudden increases in 400 Bad Request responses from backends, which often accompany smuggling probes.
- Monitor authentication and authorization decision logs for requests that reach protected endpoints without a preceding auth event.
How to Mitigate CVE-2026-93574
Immediate Actions Required
- Upgrade netty-codec-http to the fixed version distributed by the upstream Netty project or by your platform vendor.
- Apply Red Hat updates from RHSA-2026:69440 and RHSA-2026:69470 on affected Red Hat systems.
- Inventory all Java applications and middleware that embed Netty, including transitive dependencies pulled through frameworks such as Spring, gRPC, and Elasticsearch clients.
Patch Information
Red Hat has released fixes in advisories RHSA-2026:69440 and RHSA-2026:69470. Consult the Red Hat CVE page for CVE-2026-93574 for the complete list of impacted packages and fixed versions. Downstream consumers of Netty should rebuild artifacts against the patched library version and redeploy.
Workarounds
- Configure the fronting reverse proxy or WAF to strictly validate HTTP/1.1 chunked encoding and reject requests with whitespace inside the chunk-size token.
- Disable HTTP/1.1 keep-alive on affected services where feasible to prevent connection reuse that enables smuggling.
- Prefer HTTP/2 end-to-end between the proxy and Netty backend, as HTTP/2 framing is not susceptible to this chunk-parsing ambiguity.
# Configuration example: enforce strict chunked parsing at an NGINX front-end
# and reject ambiguous transfer-encoding requests before they reach Netty.
http {
# Drop requests that specify both Content-Length and Transfer-Encoding
map $http_transfer_encoding $bad_te {
default 0;
"~*chunked" 1;
}
server {
listen 443 ssl;
server_name app.example.com;
if ($bad_te = 1) {
# Force strict validation via a dedicated location
set $strict 1;
}
location / {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://netty_backend;
}
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

