REDHAT-BUG-2519953: High severity maven/io.netty/netty-handler vulnerability

Q: Which deployments are realistically exposed to authentication bypass?

Exposure requires SNI-based TLS configuration where a protected hostname relies solely on clientAuth=REQUIRE for mutual TLS, while the default SslContext permits clientAuth=NONE or clientAuth=OPTIONAL. An application that also performs certificate verification at the application layer does not meet the described bypass conditions.

Q: What does an attacker need to do to exploit this issue?

An unauthenticated remote attacker must send a TLS ClientHello whose four-byte handshake header spans TLS records. The malformed record layout can cause Netty to select the default SSL context rather than the SNI-specific context.

Q: Are default configurations affected?

The described bypass depends on a specific configuration difference between the SNI-selected SSL context and the default SSL context. The data does not establish that a default configuration is affected.

Q: Which versions contain the fix?

The issue is fixed in Netty versions 4.1.137.Final and 4.2.17.Final. Versions prior to those releases are within the stated affected range.

Published Aug 19, 2026

Updated

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.

Affected Software

1 affected component

maven/io.netty/netty-handler<4.1.137.Final, <4.2.17.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Netty to a version that resolves this vulnerability.
Fixed in 4.1.137.Final
Upgrade
Upgrade Netty to a version that resolves this vulnerability.
Fixed in 4.2.17.Final
Configuration
Configure the default SslContext to use clientAuth=REQUIRE so that mutual TLS remains enforced when the SNI-specific context is not selected.
default SslContext clientAuth = REQUIRE

Event History

Aug 19, 2026

Data Sourced

via Red Hat·09:26 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which deployments are realistically exposed to authentication bypass?

Exposure requires SNI-based TLS configuration where a protected hostname relies solely on clientAuth=REQUIRE for mutual TLS, while the default SslContext permits clientAuth=NONE or clientAuth=OPTIONAL. An application that also performs certificate verification at the application layer does not meet the described bypass conditions.

What does an attacker need to do to exploit this issue?

An unauthenticated remote attacker must send a TLS ClientHello whose four-byte handshake header spans TLS records. The malformed record layout can cause Netty to select the default SSL context rather than the SNI-specific context.

Are default configurations affected?

The described bypass depends on a specific configuration difference between the SNI-selected SSL context and the default SSL context. The data does not establish that a default configuration is affected.

Which versions contain the fix?

The issue is fixed in Netty versions 4.1.137.Final and 4.2.17.Final. Versions prior to those releases are within the stated affected range.

REDHAT-BUG-2519953: High severity maven/io.netty/netty-handler vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are realistically exposed to authentication bypass?

What does an attacker need to do to exploit this issue?

Are default configurations affected?

Which versions contain the fix?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed to authentication bypass?

What does an attacker need to do to exploit this issue?

Are default configurations affected?

Which versions contain the fix?