CVE-2021-21295

Possible request smuggling in HTTP/2 due missing validation

MEDIUM
5.9
CVSS Score
Published: March 9, 2021 at 06:35 PM UTC
Updated: October 8, 2026 at 10:17 PM UTC
8 products affected across 6 vendorsDebian LinuxOnCommand Workflow AutomationCommunications Cloud Native Core Policy

Using io.netty:netty-codec-http2 by netty?

Get instant alerts when new vulnerabilities affect io.netty:netty-codec-http2 - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
MEDIUM5.9
Exploit prediction
EPSS 19%
SSVC
No known exploit

Description

Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `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. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 1.16.0*
Affected range stops below 1.16.0, so it looks safe — our inference, not a vendor statement
v < 4.1.60v < 4.1.60.Final*
Affected range stops below 4.1.60, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.1.60.Final, so it looks safe — our inference, not a vendor statement
v ≤ 1.13.7*

SSVC — Action Prioritization

SSVCNo known exploitAutomatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

5.9MEDIUMGitHub_M
Attack Vector
NETWORK
Complexity
HIGH
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
NONE
Integrity
HIGH
Availability
NONE
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-444

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card