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

Q: Which deployments are exposed to this issue?

Exposure requires Netty's OpenSSL client TLS path, a plain non-extended X509TrustManager, and an environment where Unsafe-based trust-manager wrapping is unavailable, such as Java 25 or later. Deployments not using this specific combination are not described as affected.

Q: What does an attacker need to exploit the weakness?

An attacker needs a man-in-the-middle position on the client TLS connection and a certificate issued for a hostname other than the intended destination. Under the affected configuration, the OpenSSL client can accept that certificate without hostname validation.

Q: Are default Netty TLS client configurations affected?

The issue is conditional rather than described as affecting all default configurations. It occurs only when the OpenSSL client path uses a plain X509TrustManager and Unsafe-based trust-manager wrapping is unavailable.

Q: What versions contain the fix?

The issue is fixed in Netty netty-handler 4.2.17.Final and 4.1.137.Final. Affected releases include 4.2.0.Final through 4.2.16.Final and releases through 4.1.136.Final.

Published Aug 22, 2026

Updated

Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.16.Final and versions through 4.1.136.Final disable TLS hostname verification on the SslProvider.OPENSSL client path when a plain (non-extended) X509TrustManager is used and Unsafe-based trust-manager wrapping is unavailable (Java 25+). In this configuration the OpenSSL client does not perform hostname verification, allowing a man-in-the-middle attacker to present a certificate issued for a different hostname that is accepted without validation. Fixed in 4.2.17.Final and 4.1.137.Final.

Affected Software

1 affected component

maven/io.netty/netty-handler>=4.2.0.Final<=4.2.16.Final, <=4.1.136.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade io.netty:netty-handler to a version that resolves this vulnerability.
Fixed in 4.2.17.Final
Upgrade
Upgrade io.netty:netty-handler to a version that resolves this vulnerability.
Fixed in 4.1.137.Final

Event History

Aug 22, 2026

Data Sourced

via Red Hat·12:52 PM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which deployments are exposed to this issue?

Exposure requires Netty's OpenSSL client TLS path, a plain non-extended X509TrustManager, and an environment where Unsafe-based trust-manager wrapping is unavailable, such as Java 25 or later. Deployments not using this specific combination are not described as affected.

What does an attacker need to exploit the weakness?

An attacker needs a man-in-the-middle position on the client TLS connection and a certificate issued for a hostname other than the intended destination. Under the affected configuration, the OpenSSL client can accept that certificate without hostname validation.

Are default Netty TLS client configurations affected?

The issue is conditional rather than described as affecting all default configurations. It occurs only when the OpenSSL client path uses a plain X509TrustManager and Unsafe-based trust-manager wrapping is unavailable.

What versions contain the fix?

The issue is fixed in Netty netty-handler 4.2.17.Final and 4.1.137.Final. Affected releases include 4.2.0.Final through 4.2.16.Final and releases through 4.1.136.Final.

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

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit the weakness?

Are default Netty TLS client configurations affected?

What versions contain the fix?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to this issue?

What does an attacker need to exploit the weakness?

Are default Netty TLS client configurations affected?

What versions contain the fix?