CVE-2026-89044 in Netty
Summary
by MITRE • 09/10/2026
Netty versions 4.1.133.Final through 4.1.137.Final and 4.2.13.Final through 4.2.17.Final fail to properly validate the final transfer coding in the Transfer-Encoding header, allowing attackers to smuggle requests by using malformed encoding declarations. Attackers can split Transfer-Encoding headers across multiple lines or use values like 'chunked, xchunked' to bypass validation and decode messages as chunked when the final coding is not chunked, enabling request smuggling attacks.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The vulnerability identified in Netty versions 4.1.133.Final through 4.1.137.Final and 4.2.13.Final through 4.2.17.Final represents a critical flaw in the HTTP protocol implementation, specifically concerning the parsing of the Transfer-Encoding header. This issue stems from an insufficient validation mechanism when processing final transfer coding declarations within HTTP messages. In standard HTTP/1.1 operations, the Transfer-Encoding header indicates what form of encoding has been applied to the message body, with chunked being a common method for dynamic content delivery where data is sent in a series of non-empty chunks terminated by zero-length chunks. The flaw allows attackers to manipulate this parsing logic by introducing malformed or ambiguous encoding declarations that bypass standard security checks designed to prevent request smuggling attacks.
The technical root cause lies in how the framework interprets multiple values within the Transfer-Encoding header and handles line folding or splitting. Attackers can exploit this by splitting the Transfer-Encoding header across multiple lines, a technique known as HTTP Request Smuggling via CRLF injection or header manipulation. Alternatively, attackers may use compound values such as chunked followed by an invalid encoding like xchunked. In these scenarios, Netty incorrectly decodes messages based on the presence of chunked anywhere in the list rather than strictly validating that the final transfer coding is indeed chunked when required for proper message boundary detection. This misinterpretation leads to a state where the server believes it has received one complete HTTP request while an intermediary proxy or another part of the pipeline interprets the stream differently, creating a desynchronization between client and server expectations.
The operational impact of this vulnerability is severe, primarily facilitating HTTP Request Smuggling attacks which can lead to significant security breaches including cache poisoning, session hijacking, cross-site scripting, and access control bypasses. By exploiting the discrepancy in how requests are parsed, an attacker can inject malicious payloads into subsequent legitimate requests or redirect traffic intended for other users. This desynchronization undermines the integrity of HTTP communication channels protected by reverse proxies or load balancers that rely on accurate message boundary detection to route traffic correctly. The ability to smuggle requests effectively allows attackers to bypass front-end security controls and interact directly with backend services, potentially exposing sensitive data or allowing unauthorized administrative actions depending on the application architecture.
This vulnerability aligns closely with CWE-20 Improper Input Validation as it involves a failure to adequately sanitize and verify input headers before processing them within the HTTP stack. Furthermore, from an offensive security perspective, this flaw is directly associated with MITRE ATT&CK technique T1534 which covers Internal Reconnaissance via Network Service Scanning but more specifically relates to techniques used in conjunction with request smuggling such as T1078 Valid Accounts if session hijacking occurs or general exploitation patterns found under lateral movement and privilege escalation vectors enabled by the initial access gained through smuggling. The lack of strict adherence to RFC 9112 regarding Transfer-Encoding parsing rules highlights a deviation from established industry standards for robust HTTP implementation.
Mitigation strategies must focus on immediate patching and architectural review. Organizations running affected Netty versions should upgrade immediately to patched releases where this validation logic has been corrected to strictly enforce that the final transfer coding matches expectations before decoding message boundaries. For environments unable to update instantly, deploying Web Application Firewalls with rules specifically tuned to detect malformed Transfer-Encoding headers or split header values can provide a temporary layer of defense. Additionally, developers should review application code for any custom HTTP parsing logic and ensure compliance with RFC standards by validating that only recognized transfer codings are accepted and that the final coding in a sequence is explicitly checked against expected states before processing message bodies. Regular security audits focusing on protocol conformance will help identify similar vulnerabilities in other components of the technology stack.