Answer in brief
CVE-2026-62243 records a Unknown severity vulnerability in Netty 4.2.0 through 4.2.16 TLS Hostname Verification Bypass. The current sources do not mark it as known exploited. The current feed maps netty/netty (generic), netty/netty (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps netty/netty (generic), netty/netty (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| netty/nettygeneric | >=4.2.0.Final <4.2.16.Final | 4.2.16.Final |
| netty/nettygeneric | >=0 <4.1.137.Final | 4.1.137.Final |
Published upstream
Aug 22, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 22, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 22, 2026
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.
Quoted source text, attributed separately from HOL analysis.