Netty CVE-2026-75595

Exploitation requires a Netty deployment where ALL of the following hold: per-SNI clientAuth=REQUIRE is the sole mutual-TLS gate for the protected route; the default SslContext is configured with clientAuth=NONE or clientAuth=OPTIONAL; and there is no application-layer client-certificate verification as a backstop. The attacker-side trigger is a crafted ClientHello whose four-byte TLS handshake header is split across two TLS records, forcing the wrong-offset bounds check to fault into select(ctx, null). Limiting factors: it is NOT default-configuration exploitable - deployments not using SNI-based mTLS, or that set the default context to clientAuth=REQUIRE, or that check certs at the application layer, are not bypassable; the AT:P metric explicitly reflects this configuration dependency. No authentication and no user interaction are needed (PR:N/UI:N), and the vector is network-reachable.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H) rates this 9.1 Critical: network-reachable, no privileges, no user interaction, high confidentiality and integrity impact - but AT:P (Attack Requirements: Present) correctly signals that exploitation depends on conditions outside the attacker's control, namely a specific deployment configuration. This is the decisive nuance: the flaw is only security-relevant when per-SNI clientAuth=REQUIRE is the SOLE mTLS gate, the default SslContext uses clientAuth NONE/OPTIONAL, and there is no application-layer certificate check. Deployments that set clientAuth=REQUIRE on the default context, or that enforce client-cert identity at the application layer, are not exploitable even though they run the vulnerable code. No EPSS score, KEV listing, or POC was provided, so real-world exploitation is unproven; treat this as a high-priority patch for anyone using Netty SNI-based mTLS routing, and a lower priority for the many Netty deployments that do not use per-SNI clientAuth at all. Note the AT:P condition means raw 9.1 overstates risk for typical/default deployments.

An attacker targets a service that routes TLS by SNI and enforces mutual TLS only via per-SNI clientAuth=REQUIRE on a protected virtual host. The attacker connects and sends a ClientHello deliberately fragmented so the four-byte handshake header spans two TLS records; Netty throws IndexOutOfBoundsException, selects the default SslContext (clientAuth NONE/OPTIONAL), and completes the handshake without ever requiring a client certificate, granting access to the protected route. No POC was provided in the intelligence, so this scenario is inferred from the description and CVSS vector.