External risk intelligence

Netty SNI TLS Bypass Vulnerability.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-75595

Netty is a widely used framework for building network applications, including high-performance web servers, API gateways, and edge services that are directly exposed to the internet. Since this vulnerability affects TLS handshake processing, it is highly relevant to public-facing services that manage incoming connections and rely on SNI-based routing or mutual TLS configurations.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a vulnerability in Netty, a framework used for building network applications. The issue allows an unauthenticated remote attacker to bypass mutual TLS authentication requirements in certain configurations. The main concern is confirming relevance and exposure within affected systems.

Attackers can bypass authentication controls.
Matters if using mutual TLS for access.
Confirm relevance and system exposure.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker could bypass mutual TLS requirements by sending a specially crafted ClientHello message. This message, designed to span multiple records, tricks the Netty handler into using a default SSL context instead of one configured for server name indication (SNI), thereby bypassing application-layer certificate verification.

Network access needed.
Malformed TLS handshake triggers vulnerability.
Bypasses mutual TLS authentication.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, an unauthenticated remote attacker could bypass mutual TLS requirements on protected routes. This bypass occurs when the sole mutual TLS gate relies on per-SNI client authentication, and the default SslContext is used instead of the SNI-specific one, due to an incorrect offset check during the TLS handshake header read.

Protected routes could be accessed without authentication.
Attacker bypasses mutual TLS requirement.
Unauthorized access to sensitive data or services.

Operational Fix

Recommended remediation, mitigation, and detection steps

Platform or application teams managing Netty deployments are likely responsible for addressing this vulnerability. The initial focus should be on identifying all instances of the affected Netty versions, determining their exposure to external clients, and confirming if they are configured for mutual TLS with client authentication. Once identified and prioritized, a remediation plan should be developed, coordinating with relevant application owners and potentially vendor management if Netty is part of a third-party solution.

Identify affected Netty instances and exposure.
Verify SNI-specific mutual TLS configurations.
Plan and coordinate risk-based remediation.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Netty and how is it used?

Netty is a high-performance, asynchronous framework developers use to build network applications. It acts as the backbone for many modern web servers, API gateways, and edge services. Because it handles low-level networking tasks like data transmission and connection management, it is foundational to systems that require efficient, scalable communication over the internet.

What does CVE-2026-75595 mean for my software?

This vulnerability, classified as an improper check for unusual or exceptional conditions (CWE-754), occurs when Netty processes TLS handshakes. Because of a calculation error in the code, the system fails to correctly identify which security rules to apply when a handshake message is split across multiple data records. This flaw can cause the software to ignore specific security settings meant to enforce strict identification for incoming connections.

How does an attacker trigger this TLS handshake bypass?

An attacker initiates this by sending a specially crafted TLS ClientHello message that spans multiple records. This structure misleads the Netty handler into misreading the handshake header offset. It is important to note that standard, well-formed TLS connections do not trigger this error; the issue specifically arises from malformed handshake data designed to manipulate how the framework selects its security context.

Do I need to worry if my Netty service is internal?

According to Halo Surface Signal, this vulnerability is most relevant to public-facing services that manage incoming connections and rely on specific SNI-based routing or mutual TLS. While any vulnerable instance is technically at risk, the danger is highest for internet-exposed systems. If your service uses per-SNI mutual TLS as its primary security gate, it is a priority for investigation, regardless of its specific network location.

How should I respond to CVE-2026-75595?

Begin by auditing your environment to locate all applications using affected Netty versions. Prioritize systems that perform mutual TLS authentication based on server name indication (SNI). Once identified, coordinate with your development teams to update to version 4.1.137.Final or 4.2.17.Final, which include the necessary fixes for the TLS handshake header logic. Ensure your remediation plan accounts for any third-party software that may embed these vulnerable Netty libraries.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.