CVE-2026-62243
Received Received - Intake

Netty TLS Hostname Verification Bypass via Unsafe TrustManager

Publication date: 2026-08-22

Last updated on: 2026-08-22

Assigner: VulnCheck

Description
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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-22
Last Modified
2026-08-22
Generated
2026-08-22
AI Q&A
2026-08-22
EPSS Evaluated
N/A
NVD
CVE-2026-62243
EUVD
EUVD-2026-64271

Affected Vendors & Products

Showing 6 associated CPEs
Vendor Product Version / Range
netty netty-handler From 4.2.0.Final (inc) to 4.2.16.Final (inc)
netty netty-handler to 4.1.136.Final (inc)
netty netty-handler 4.2.17.Final
netty netty-handler 4.1.137.Final
netty netty From 4.2.0 (inc) to 4.2.16 (inc)
netty netty From 4.1.0 (inc) to 4.1.136 (inc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-297 The product communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

CVE-2026-62243 is a TLS hostname verification bypass in Netty versions 4.2.0.Final through 4.2.16.Final and 4.1.136.Final or earlier. When using the OpenSSL client path with a plain X509TrustManager and Unsafe-based trust-manager wrapping is unavailable (e.g., Java 25+), hostname verification is disabled. This allows a man-in-the-middle attacker to present a certificate for a different hostname that is accepted without validation.

Detection Guidance

To detect this vulnerability, check your Netty version using commands like 'mvn dependency:tree' for Maven or 'gradle dependencies' for Gradle to identify if you are using versions 4.2.0.Final to 4.2.16.Final or 4.1.136.Final or earlier. Additionally, verify if your application uses SslProvider.OPENSSL with a plain X509TrustManager in Java 25+ environments.

Impact Analysis

This vulnerability allows attackers to intercept and decrypt sensitive data transmitted over TLS by bypassing hostname verification. It poses a high risk to confidentiality as unauthorized parties may access data intended for a different host. The attack requires no privileges or user interaction and can be executed remotely with low complexity.

Compliance Impact

This vulnerability could lead to non-compliance with GDPR and HIPAA due to unauthorized data access. GDPR requires protection of personal data, and HIPAA mandates secure transmission of health information. A breach via this vulnerability may result in legal penalties, reputational damage, and loss of trust.

Mitigation Strategies

Upgrade Netty to versions 4.2.17.Final or 4.1.137.Final or later immediately. If upgrading is not possible, avoid using SslProvider.OPENSSL with plain X509TrustManager in Java 25+ environments or implement custom hostname verification logic.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-62243. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart