Netty-Handler (Vulnerable: <= 4.1.136.Final) - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/netty-handler-vulnerable--4.1.136.final/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioTue, 08 Sep 2026 20:04:42 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgNetty SNI Routing and mTLS Bypass Vulnerabilityhttps://feed.craftedsignal.io/briefs/2026-09-netty-sni-bypass/Tue, 08 Sep 2026 20:04:42 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-09-netty-sni-bypass/A vulnerability in the Netty TLS ClientHello parsing logic allows unauthenticated attackers to bypass SNI-based mTLS requirements by sending fragmented handshake data that triggers a fallback to a permissive default SSL context.The Netty framework contains a vulnerability (CVE-2026-75595) in io.netty.handler.ssl.SslClientHelloHandler where the parser incorrectly validates the TLS ClientHello handshake header. Specifically, the implementation fails to account for the 5-byte TLS record header when calculating the offset for the handshake length. If a client sends a fragmented TLS ClientHello such that the first record's payload is less than 4 bytes, the parser encounters an IndexOutOfBoundsException. This exception is caught by a generic handler that silently falls back to the default SslContext.

This flaw becomes a critical security risk when mTLS is enforced exclusively through per-SNI SslContext selection. If an organization relies on SNI-based routing to apply mTLS requirements (clientAuth=REQUIRE) but maintains a permissive default SslContext (clientAuth=NONE or OPTIONAL) for fallback, an unauthenticated attacker can bypass the intended mTLS protection by intentionally fragmenting the initial TLS handshake to trigger the fallback logic.

Impact

Successful exploitation allows an unauthenticated attacker to bypass mTLS authentication controls on affected systems. This impacts any environment relying on per-SNI SslContext selection as the primary mechanism for mTLS enforcement without secondary application-layer peer-certificate validation. Depending on the backend application, this could lead to unauthorized access to internal services or API endpoints that expect authenticated client traffic.

Recommendation

Prioritize the upgrade of all applications using the netty-handler library to patched versions. As this is a library-level vulnerability, detection engineering should focus on application-layer logging and monitoring of TLS connection configurations.

  • Upgrade io.netty:netty-handler to version 4.1.137.Final or 4.2.17.Final or later, as provided by the vendor.
  • Review server-side TLS configurations to ensure that the default SslContext is not configured with permissive client authentication (clientAuth=NONE) if the application handles sensitive routes.
  • Implement application-layer peer-certificate validation to ensure that mTLS requirements are enforced regardless of the initial TLS routing context.
]]>criticaladvisory