CVE-2026-93573: Netty HTTP/1.1 Auth Bypass Vulnerability

CVE-2026-93573 Overview

A flaw in Netty's HTTP/1.1 decoder allows remote attackers to bypass Transfer-Encoding header validation. The decoder fails to reject requests when the Transfer-Encoding field is split across multiple headers and the last field contains a non-final transfer coding such as gzip or deflate. This weakness enables HTTP request smuggling [CWE-444], allowing attackers to desynchronize front-end and back-end request processing. Successful exploitation can bypass security controls, poison caches, or cause requests to be processed in an unintended context.

Critical Impact

Remote attackers can smuggle HTTP requests through Netty-based proxies and application servers, bypassing perimeter security controls without authentication or user interaction.

Affected Products

• Netty HTTP/1.1 decoder (io.netty:netty-codec-http)
• Red Hat products bundling vulnerable Netty releases (see RHSA-2026:69440)
• Red Hat products bundling vulnerable Netty releases (see RHSA-2026:69470)

Discovery Timeline

• 2026-09-18 - CVE-2026-93573 published to the National Vulnerability Database
• 2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-93573

Vulnerability Analysis

The vulnerability resides in how Netty's HTTP/1.1 decoder parses and validates the Transfer-Encoding request header. RFC 7230 requires that when Transfer-Encoding is present, chunked must be the final transfer coding. Netty enforces this rule when a single Transfer-Encoding header is supplied but fails to enforce it correctly when the field is split across multiple header lines. An attacker who submits two Transfer-Encoding headers, where the second header specifies gzip or deflate instead of chunked, evades the check.

This validation gap creates a parsing discrepancy between Netty and upstream intermediaries such as reverse proxies or load balancers. The resulting desynchronization is the basis for HTTP request smuggling attacks.

Root Cause

The root cause is incomplete header field aggregation during validation. Netty evaluates each Transfer-Encoding header value independently rather than concatenating all field instances into a single logical value before applying the final-coding check, as HTTP messaging semantics require.

Attack Vector

Exploitation requires only network access to a service that fronts or is fronted by a Netty-based HTTP/1.1 endpoint. The attacker crafts a request containing multiple Transfer-Encoding headers with a non-chunked final value. If the front-end proxy and the Netty back-end interpret the message boundaries differently, the attacker can prepend or append data to subsequent legitimate requests. Consult the Red Hat CVE Analysis for CVE-2026-93573 for message-level details.

No verified public proof-of-concept code is available. The vulnerability mechanism is described in prose rather than reproduced as exploit code.

Detection Methods for CVE-2026-93573

Indicators of Compromise

• HTTP requests containing multiple Transfer-Encoding headers within a single message
• Transfer-Encoding headers where the final coding is gzip, deflate, or any value other than chunked
• Unexpected request pairings in application logs, such as responses returned to the wrong client session
• Cache entries containing content that does not match the requested URL

Detection Strategies

• Inspect raw HTTP traffic at the ingress layer for duplicate Transfer-Encoding header instances
• Compare request framing decisions between the front-end proxy and the Netty back-end to identify parsing disagreements
• Alert on any request where Transfer-Encoding and Content-Length are both present or where Transfer-Encoding appears more than once

Monitoring Recommendations

• Enable verbose HTTP request logging on reverse proxies to capture full header sets, not only normalized values
• Forward web server and application logs to a centralized analytics platform for cross-tier correlation
• Baseline normal Transfer-Encoding usage in your environment; treat any non-chunked final coding as anomalous

How to Mitigate CVE-2026-93573

Immediate Actions Required

• Inventory all applications and middleware that embed Netty and identify the bundled version
• Apply vendor updates from the Red Hat Security Advisory RHSA-2026:69440 and Red Hat Security Advisory RHSA-2026:69470
• Configure upstream proxies to reject requests containing multiple Transfer-Encoding headers before they reach Netty
• Review web access logs for the past 90 days for smuggling indicators

Patch Information

Red Hat has released fixes tracked under RHSA-2026:69440 and RHSA-2026:69470. Netty maintainers have addressed the header aggregation logic so that all Transfer-Encoding field instances are joined and validated as a single value. Refer to Red Hat Bug Report #2536964 for tracking details and to the Red Hat CVE Analysis for CVE-2026-93573 for downstream package mapping.

Workarounds

• Deploy a strict HTTP-compliant reverse proxy in front of Netty services to normalize or reject ambiguous framing
• Configure web application firewall rules to block requests with duplicate Transfer-Encoding headers
• Disable HTTP/1.1 pipelining on affected endpoints where feasible to reduce smuggling opportunities
• Enforce HTTP/2 end-to-end where the client and infrastructure support it

# Example ModSecurity rule to block duplicate Transfer-Encoding headers
SecRule REQUEST_HEADERS_NAMES "@streq transfer-encoding" \
  "id:1009301,phase:1,deny,status:400,\
  msg:'Duplicate or invalid Transfer-Encoding header (CVE-2026-93573)',\
  chain"
  SecRule &REQUEST_HEADERS:Transfer-Encoding "@gt 1"