CVE-2026-93568: Io.netty/netty-codec-http2: io.netty/netty-codec-http3: netty: http/2 and http/3 extended connect requests are downgraded as regular connect requests
HTTP/2 and HTTP/3 Extended CONNECT requests are downgraded as regular CONNECT requests
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven:io.netty:netty-codec-http2to a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade
maven:io.netty:netty-codec-http2to a version that resolves this vulnerability.Fixed in 4.2.17.Final - Upgrade
Upgrade
maven:io.netty:netty-codec-http3to a version that resolves this vulnerability.Fixed in 4.2.15.Final - Configuration
If maintainers prefer not to support Extended CONNECT through Netty's HTTP-object API, fail closed: in HttpConversionUtil.toHttpRequest(...) reject Extended CONNECT requests (so downstream HTTP-object handlers cannot confuse them with regular CONNECT). Keep regular CONNECT behavior unchanged.
Netty HTTP/2 or HTTP/3 HTTP-object conversion path (HttpConversionUtil.toHttpRequest(...)) Extended CONNECT handling = fail-closed (do not convert Extended CONNECT into an ordinary HTTP/1 CONNECT object) - Compensating control
In gateway/proxy/application-server/protocol-bridging deployments that use Netty's HTTP-object conversion path, require Extended CONNECT to be handled at the native HTTP/2 or HTTP/3 frame/header layer (instead of relying on the HTTP-object conversion path) so routing/authorization logic cannot be bypassed by downgrading to regular HTTP/1.1 CONNECT.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using Netty HTTP/2 or HTTP/3 HTTP-object conversion paths are exposed when downstream handlers make security decisions based on distinguishing ordinary CONNECT tunnels from Extended CONNECT requests. After conversion, the downstream HTTP-object API no longer retains the Extended CONNECT :protocol value or :path.
What does an attacker need to exploit it?
The issue is network-reachable and requires neither authentication nor user interaction. An attacker needs to send an HTTP/2 or HTTP/3 Extended CONNECT request through an affected conversion path to a downstream handler that relies on the lost request semantics.
What is the likely security impact?
A downstream handler may treat an Extended CONNECT request as a regular CONNECT tunnel because it cannot distinguish the two after conversion. The provided severity vector rates integrity impact as high, with no confidentiality or availability impact indicated.