Live › vulnerability › CVE-2026-116542
Go to dashboardnetty-tcnative before 2.0.84.Final decodes the TLS ClientHello server_name field with JNI NewStringUTF, which accepts overlong UTF-8 encodings such as 0xC0 0x80. A remote unauthenticated client can therefore present a hostname that differs from what it sent, confusing SNI-based certificate selection, access decisions and logs.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 16:31 UTC. All times on this page are UTC.
Java services that terminate TLS through Netty with the native tcnative (OpenSSL or BoringSSL) SSL provider and rely on SNI hostnames to pick certificates, route requests or make access decisions. Services using the JDK SSL provider or no SNI-dependent logic are less exposed. unknown whether the sources list specific affected deployment patterns beyond this.
No product ranges from the sources yet.
io.netty:netty-tcnative or netty-tcnative-boringssl-static in the dependency tree (for example mvn dependency:tree or gradle dependencies) and note the version.io.netty:netty-tcnative (and the netty-tcnative-boringssl-static artifact) to 2.0.84.Final or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Netty netty-tcnative before 2.0.84.Final contains an SNI hostname spoofing vulnerability that allows remote unauthenticated clients to alter hostnames via JNI NewStringUTF decoding. Attackers can send overlong encodings like 0xC0 0x80 in the ClientHello server_name to confuse SNI-based certificate selection, access decisions, and logging.
This page as .md · .json · in your agent: get_signal("CVE-2026-116542")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.