Описание
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.
A flaw was found in Netty (io.netty:netty-handler). When using the SslProvider.OPENSSL client path with a plain X509TrustManager and without Unsafe-based trust-manager wrapping (Java 25+), TLS hostname verification is disabled. This misconfiguration allows a man-in-the-middle attacker to present a fraudulent certificate for a different hostname, which is then accepted without proper validation. This could lead to sensitive information disclosure.
Отчет
Red Hat products ship io.netty:netty-handler as a transitive dependency across multiple middleware and platform products. While the CVSS score reflects the severity of a successful exploit — full confidentiality compromise of TLS-protected traffic without authentication — the vulnerable code path requires three conditions simultaneously: explicit OpenSSL provider configuration, a plain X509TrustManager, and a Java 25+ runtime. Most Red Hat product deployments use the default JDK SSL provider and currently run on Java 21 LTS, making the vulnerable configuration uncommon in practice.
Меры по смягчению последствий
This vulnerability only affects applications that explicitly configure Netty to use the OpenSSL TLS provider (SslProvider.OPENSSL). The following mitigations can reduce exposure without applying a patch:
- Use the default JDK SSL provider — Do not configure SslProvider.OPENSSL in your Netty SslContext setup. The default JDK SSL provider (SslProvider.JDK) is not affected by this vulnerability. Most applications use the JDK default unless explicitly overridden.
- Use X509ExtendedTrustManager — If the OpenSSL provider is required, ensure the configured trust manager extends X509ExtendedTrustManager rather than the plain X509TrustManager interface. The extended variant performs hostname verification independently of the Netty wrapping logic.
- Run on Java 24 or earlier — The vulnerable code path only triggers on Java 25+ where sun.misc.Unsafe-based trust-manager wrapping is unavailable. Running on earlier Java versions (e.g., Java 21 LTS) means the wrapping works correctly and hostname verification stays enabled.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Exploit Intelligence | exploit-intelligence/agent-client-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-ekb-dispatcher-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-ekb-receiver-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-ddb-streams-source-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-s3-sink-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-s3-source-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-sns-sink-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-sqs-sink-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-aws-sqs-source-rhel9 | Affected | ||
| OpenShift Serverless | openshift-serverless-1/kn-eventing-integrations-log-sink-rhel9 | Affected |
Показывать по
Дополнительная информация
Статус:
EPSS
7.5 High
CVSS3
Связанные уязвимости
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.
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.
Netty (io.netty:netty-handler) versions from 4.2.0.Final through 4.2.1 ...
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.
EPSS
7.5 High
CVSS3