Netty: OpenSSL client path silently skips TLS hostname verification on Java 25+

Impact

On the SslProvider.OPENSSL client path, when the application supplies a plain X509TrustManager and the Unsafe-based wrapping Netty relies on is unavailable - which is the case on Java 25 and later - hostname verification is not performed at all. The certificate chain still has to validate, but a certificate issued for any other name is accepted, so an on-path attacker can terminate the connection and read or alter the traffic. Netty is the transport under a large share of the JVM infrastructure a datacenter runs: object and metadata stores, message brokers, gRPC-java services, query engines, and cluster clients that carry credentials in-band. The failure is silent - nothing logs a downgrade - so an operator has no signal that a connection was not verified. The preconditions are narrow, and a service on an older JDK or the JDK SSL provider is unaffected.

Who can reach it

An attacker positioned on the network path between the Netty-based client and the server it connects to - between availability zones, on a shared fabric, or anywhere TLS is the only thing separating tenants. No authentication is needed. The affected side is the client, so this hits services that dial out, not ones that only accept connections.

What to do

Upgrade netty-handler to 4.2.17.Final or 4.1.137.Final, rebuild the affected services and restart them - a rolling daemon restart, no node drain. Both the 4.2.x line through 4.2.16.Final and everything through 4.1.136.Final are affected. Where you cannot rebuild immediately, the exposure disappears if the service runs on a JDK earlier than 25, uses the JDK SSL provider instead of SslProvider.OPENSSL, or is configured with an X509ExtendedTrustManager; check which of those you already have before scheduling work.

References

Related entries

• Pure Storage FlashArray Purity (data path information exposure): Insufficient filtering on certain data paths exposesCVE-2026-6445 · Pure Storage FlashArray Purity (data path information exposure)High
• HPE iLO3/4/5: Remote unauthenticated denial of service against the management controllerCVE-2018-7093 · HPE iLO3/4/5High
• NAKIVO Backup & Replication: Unauthenticated absolute path traversal via getImageByPathCVE-2024-48248 · NAKIVO Backup & ReplicationHigh
• Socomec DIRIS Digiware M-70 1.6.9 (Modbus TCP and Modbus RTU-over-TCP): A large cluster of unauthenticated ModbusCVE-2024-48882 · Socomec DIRIS Digiware M-70 1.6.9 (Modbus TCP and Modbus RTU-over-TCP)High
• Ivanti Endpoint Manager (EPM): Auth bypass via alternate pathCVE-2026-1603 · Ivanti Endpoint Manager (EPM)High
• Pure Storage FlashArray Purity (management interface privilege bypass): An authenticated low-privileged user reachesCVE-2026-6444 · Pure Storage FlashArray Purity (management interface privilege bypass)High