CVE-2021-21295 Overview
CVE-2021-21295 is an HTTP Request Smuggling vulnerability in Netty, the popular open-source asynchronous event-driven network application framework. The vulnerability exists in the io.netty:netty-codec-http2 component prior to version 4.1.60.Final, where the Content-Length header is not validated by Http2MultiplexHandler when HTTP/2 requests are converted and proxied as HTTP/1.1.
When an HTTP/2 stream is received and converted to HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec, and then forwarded to a backend HTTP/1.1 connection, the unvalidated Content-Length header can be exploited. An attacker can smuggle additional requests inside the body of a legitimate request as the protocol is downgraded from HTTP/2 to HTTP/1.1.
Critical Impact
Attackers can bypass security controls, poison web caches, hijack user sessions, and perform unauthorized actions by smuggling malicious requests through proxy servers using unvalidated Content-Length headers during HTTP/2 to HTTP/1.1 protocol conversion.
Affected Products
- Netty versions prior to 4.1.60.Final
- NetApp OnCommand API Services
- NetApp OnCommand Workflow Automation
- Debian Linux 10.0
- Quarkus (affected versions)
- Apache Kudu (affected versions)
- Apache ZooKeeper 3.5.9
- Oracle Communications Cloud Native Core Policy 1.14.0
Discovery Timeline
- 2021-03-09 - CVE-2021-21295 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2021-21295
Vulnerability Analysis
This vulnerability is classified as CWE-444 (Inconsistent Interpretation of HTTP Requests, also known as HTTP Request Smuggling). The flaw occurs in environments where Netty acts as a proxy, converting HTTP/2 traffic to HTTP/1.1 for backend communication.
The attack is possible when all three conditions are met: HTTP2MultiplexCodec or Http2FrameCodec is used, Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. In such configurations, the Content-Length header from the original HTTP/2 request propagates without validation through the conversion pipeline.
HTTP/2's binary framing protocol inherently handles message boundaries differently than HTTP/1.1, which relies on Content-Length or Transfer-Encoding headers. When the unvalidated Content-Length is passed to an HTTP/1.1 backend, the backend server interprets the message boundaries according to that header, allowing attackers to embed smuggled requests within the message body.
Root Cause
The root cause is the absence of Content-Length validation in the Http2MultiplexHandler when HTTP/2 frames are converted to HTTP/1.1 objects. While HTTP/2 uses framing for message delineation, the Content-Length header becomes semantically significant once converted to HTTP/1.1. The Http2StreamFrameToHttpObjectCodec preserves the original headers without verifying that the Content-Length matches the actual payload size, creating a desynchronization opportunity between the proxy and backend server.
Attack Vector
The attack requires network access to a vulnerable Netty-based proxy that converts HTTP/2 to HTTP/1.1. An attacker crafts an HTTP/2 request with a manipulated Content-Length header that doesn't match the actual body length. When this request is forwarded to the HTTP/1.1 backend, the backend interprets the Content-Length literally, reading either too much or too little of the connection stream. The remainder (or excess) is interpreted as the beginning of a new request, allowing the attacker to inject arbitrary HTTP requests that bypass front-end security controls.
// Security patch in codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java
// Merge pull request from GHSA-wm47-8v5p-wjpj
package io.netty.handler.codec.http;
import static io.netty.util.internal.ObjectUtil.checkPositive;
-import static io.netty.util.internal.StringUtil.COMMA;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
Source: Netty Commit 89c241e
Detection Methods for CVE-2021-21295
Indicators of Compromise
- Unusual HTTP/2 to HTTP/1.1 proxy behavior with mismatched Content-Length values in backend server logs
- Unexpected requests appearing in backend server logs that were not initiated by legitimate clients
- Web cache poisoning indicators where cached responses contain unexpected or malicious content
- Session anomalies where users receive responses intended for other sessions
Detection Strategies
- Monitor proxy logs for Content-Length header mismatches between HTTP/2 frontend and HTTP/1.1 backend connections
- Implement deep packet inspection to detect HTTP request smuggling patterns in traffic between proxy tiers
- Deploy web application firewalls (WAF) with HTTP desync detection capabilities
- Audit application dependencies for Netty versions prior to 4.1.60.Final using software composition analysis tools
Monitoring Recommendations
- Enable verbose logging on Netty-based proxies to capture Content-Length header values during protocol conversion
- Set up alerts for abnormal request patterns on backend HTTP/1.1 servers that may indicate smuggled requests
- Monitor for unexpected administrative actions or data access that could result from smuggled requests bypassing authentication
- Track dependency versions across all applications using Netty to identify vulnerable deployments
How to Mitigate CVE-2021-21295
Immediate Actions Required
- Upgrade Netty to version 4.1.60.Final or later immediately across all affected systems
- Audit all applications using Netty's HTTP/2 codec components to identify vulnerable proxy configurations
- Review network architecture to identify HTTP/2 to HTTP/1.1 conversion points that may be vulnerable
- Implement the custom ChannelInboundHandler workaround if immediate patching is not possible
Patch Information
The vulnerability has been patched in Netty version 4.1.60.Final. The fix ensures proper validation of Content-Length headers during the HTTP/2 to HTTP/1.1 conversion process. Organizations should update their Netty dependencies by modifying their build configuration (Maven, Gradle, etc.) to use version 4.1.60.Final or later. Additional vendor-specific patches are available from Oracle, Debian, and NetApp.
Workarounds
- Implement a custom ChannelInboundHandler that validates Content-Length headers and place it in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec
- Configure backend HTTP/1.1 servers to reject requests with suspicious Content-Length mismatches
- Consider temporarily disabling HTTP/2 to HTTP/1.1 conversion if the functionality is not critical
- Deploy a WAF rule to detect and block HTTP request smuggling attempts at the network perimeter
// Custom ChannelInboundHandler workaround example placement
// Add validation handler behind Http2StreamFrameToHttpObjectCodec in the pipeline
pipeline.addAfter(
"http2StreamFrameToHttpObjectCodec",
"contentLengthValidator",
new ContentLengthValidationHandler()
);
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


