CVE-2026-62243
Description
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.
Statement
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.
Mitigation
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:
1) 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.
2) 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.
3) 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.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | N/A | 7.5 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | None | N/A | None |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Understanding the Weakness (CWE)
Integrity,Authentication
Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity
When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
