CVE-2021-43797 Overview
CVE-2021-43797 is an HTTP Request Smuggling vulnerability affecting Netty, an asynchronous event-driven network application framework widely used for building high-performance protocol servers and clients. The vulnerability exists in Netty versions prior to 4.1.71.Final, where the framework incorrectly handles control characters at the beginning or end of HTTP header names.
Instead of rejecting malformed headers containing control characters as required by the HTTP specification, Netty silently skips these characters and "sanitizes" the header names. When Netty is deployed as a proxy, this behavior allows attackers to craft malicious HTTP requests that bypass security controls on downstream systems.
Critical Impact
Attackers can exploit this vulnerability to perform HTTP request smuggling attacks, potentially bypassing authentication, gaining unauthorized access to protected resources, or poisoning web caches when Netty operates as a proxy server.
Affected Products
- Netty versions prior to 4.1.71.Final
- Quarkus (all versions using vulnerable Netty)
- NetApp OnCommand Workflow Automation
- NetApp SnapCenter
- Oracle Banking Deposits and Lines of Credit Servicing 2.7
- Oracle Banking Party Management 2.7.0
- Oracle Banking Platform 2.6.2
- Oracle Coherence 12.2.1.4.0 and 14.1.1.0.0
- Oracle Communications Cloud Native Core (multiple products)
- Oracle Helidon 1.4.10 and 2.4.0
- Oracle PeopleSoft Enterprise PeopleTools 8.58 and 8.59
- Debian Linux 10.0 and 11.0
Discovery Timeline
- 2021-12-09 - CVE-2021-43797 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2021-43797
Vulnerability Analysis
The vulnerability stems from improper input validation in Netty's HTTP header parsing logic. According to RFC 7230, HTTP header names must not contain control characters (characters with ASCII values 0x00-0x1F and 0x7F). However, vulnerable versions of Netty fail to enforce this requirement properly.
When processing HTTP requests, Netty's DefaultHttpHeaders and HttpObjectDecoder classes skip over control characters at the beginning and end of header names rather than rejecting the malformed request outright. This permissive parsing creates a security gap when Netty is deployed in a proxy configuration.
The attack scenario occurs when an attacker sends a crafted HTTP request with control characters embedded in header names. Netty strips these characters and forwards a "cleaned" request to the backend server. Since the backend server only sees the sanitized request, it processes headers differently than Netty interpreted them, enabling request smuggling attacks.
Root Cause
The root cause is insufficient validation in the validateHeaderNameElement method within DefaultHttpHeaders.java. The original implementation failed to reject control characters in the range 0x1c through 0x1f, as well as other forbidden characters at header name boundaries. The HttpObjectDecoder also improperly used findNonWhitespace with a flag that allowed control characters to be silently skipped rather than treated as validation failures.
Attack Vector
This vulnerability is exploitable over the network without authentication. An attacker can craft HTTP requests with strategically placed control characters in header names. When these requests pass through a Netty-based proxy, the control characters are stripped, potentially allowing the attacker to:
- Smuggle additional HTTP requests hidden within a single connection
- Bypass front-end security controls that rely on header inspection
- Poison web caches with malicious content
- Access resources that should be protected by proxy-level authentication
The security patch adds explicit validation for control characters 0x1c, 0x1d, 0x1e, and 0x1f:
private static void validateHeaderNameElement(byte value) {
switch (value) {
+ case 0x1c:
+ case 0x1d:
+ case 0x1e:
+ case 0x1f:
case 0x00:
case '\t':
case '\n':
Source: GitHub Commit Update
The decoder was also updated to properly handle whitespace detection:
int valueStart;
int valueEnd;
- nameStart = findNonWhitespace(sb, 0, false);
+ nameStart = findNonWhitespace(sb, 0);
for (nameEnd = nameStart; nameEnd < length; nameEnd ++) {
char ch = sb.charAtUnsafe(nameEnd);
// https://tools.ietf.org/html/rfc7230#section-3.2.4
Source: GitHub Commit Update
Detection Methods for CVE-2021-43797
Indicators of Compromise
- HTTP requests containing control characters (ASCII 0x00-0x1F) in header names
- Discrepancies between frontend proxy logs and backend server logs for the same request
- Unusual HTTP request patterns with malformed or unexpected header structures
- Cache poisoning incidents affecting applications behind Netty proxies
Detection Strategies
- Deploy web application firewalls (WAF) with rules to detect control characters in HTTP header names
- Implement deep packet inspection to identify HTTP requests with non-printable characters in headers
- Enable verbose logging on Netty instances to capture raw request data before sanitization
- Use SentinelOne Singularity to monitor for anomalous network traffic patterns indicative of request smuggling attempts
Monitoring Recommendations
- Monitor for sudden increases in HTTP 400 errors after patching, which may indicate blocked attack attempts
- Review access logs for requests that bypass expected authentication or authorization patterns
- Implement alerting for cache inconsistencies that could indicate successful cache poisoning
- Track dependency versions across your software inventory to identify vulnerable Netty installations
How to Mitigate CVE-2021-43797
Immediate Actions Required
- Upgrade Netty to version 4.1.71.Final or later immediately
- Audit all applications using Netty as a dependency, including transitive dependencies through frameworks like Quarkus
- Review proxy configurations to ensure Netty is not exposed to untrusted traffic until patched
- Apply vendor-specific patches for affected Oracle, NetApp, and Debian products
Patch Information
The vulnerability is fixed in Netty version 4.1.71.Final. The patch commit 07aa6b5938a8b6ed7a6586e066400e2643897323 adds proper validation for control characters in HTTP header names, causing the parser to fail fast when invalid characters are detected rather than silently sanitizing them.
For detailed patch information, refer to the GitHub Security Advisory. Oracle customers should consult the Oracle CPU April 2022 Alert and Oracle CPU July 2022 Alert for product-specific guidance.
Workarounds
- Deploy a reverse proxy or WAF in front of Netty that validates HTTP headers according to RFC 7230 before forwarding requests
- Implement custom input validation at the application layer to reject requests with control characters in header names
- If upgrading is not immediately possible, restrict network access to Netty-based services to trusted sources only
- Consider disabling proxy functionality in Netty applications until the patch can be applied
# Check Netty version in Maven projects
mvn dependency:tree | grep netty
# Check Netty version in Gradle projects
gradle dependencies | grep netty
# Update to patched version in Maven pom.xml
# <dependency>
# <groupId>io.netty</groupId>
# <artifactId>netty-all</artifactId>
# <version>4.1.71.Final</version>
# </dependency>
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

