Netty: SNI Routing Bypass via Fragmented TLS ClientHello Causing Fallback to Default SslContext
28Vexday Risk Score
Sin señal de explotación. Ningún artefacto público de explotación conocido hasta ahora.
ssvc Trackcvss 9.1epss 0.3%
probabilidad de explotación
0.3%top 75% de las CVE
explotación observada
noninguna fuente lo reporta
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Fina and 4.2.17.Final, io.netty.handler.ssl.SslClientHelloHandler#decode checks the wrong offset before reading the four-byte TLS handshake header, so a ClientHello whose handshake header spans records can cause an IndexOutOfBoundsException and invoke select(ctx, null). This selects the default SslContext instead of the SNI-specific context. In deployments where per-SNI clientAuth=REQUIRE is the sole mutual TLS gate, the default SslContext uses clientAuth=NONE or clientAuth=OPTIONAL, and no application-layer certificate verification exists, an unauthenticated remote attacker can bypass the protected route's mutual TLS requirement. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Productos afectados
netty · nettyReferencias
https://github.com/netty/netty/commit/1b5abc6443b63726c72cdd285af2feb7ddbb8ff7https://github.com/netty/netty/commit/9e0519239108a69b7e9bbc5e9182ee139a0d7961https://github.com/netty/netty/pull/17213https://github.com/netty/netty/pull/17217https://github.com/netty/netty/releases/tag/netty-4.1.137.Finalhttps://github.com/netty/netty/releases/tag/netty-4.2.17.Finalhttps://github.com/netty/netty/security/advisories/GHSA-c4c3-7fpv-j4q5