The vulnerability resides in the Netty framework’s TLS handshake processing. A ClientHello whose 4‑byte handshake header is split across fragmented records causes the decoder to read from an incorrect offset, leading to an IndexOutOfBoundsException. The resulting exception triggers a path that selects the default SSL context instead of the SNI‑specific context. When an application configures per‑SNI client authentication as REQUIRED, this default context typically allows no client authentication, effectively removing the mutual TLS requirement. Consequently, an unauthenticated attacker can gain access to routes that should be protected by client certificates.

Netty:Netty framework versions older than 4.1.137.Final and 4.2.17.Final are affected. Upgrading to version 4.1.137.Final or later, or 4.2.17.Final or later, applies the fix.

With a CVSS score of 9.1, this bug is considered critical. The EPSS score is not available and the issue is not listed in CISA’s KEV catalog. The likely attack vector is a crafted, fragmented TLS ClientHello sent over the network to a service that uses Netty with SNI. No additional privileges are required; simply sending the malformed packet can bypass the mutual TLS gate. The exploit’s success hinges on the server being configured to use the default SSL context when the SNI context cannot be resolved, which is the case when the fault occurs.