Live › vulnerability › CVE-2026-116539
Go to dashboardNetty's netty-tcnative library, before 2.0.84.Final, has a heap buffer overflow in its BIO write callback during TLS handshake, renegotiation, or post-handshake messages. A remote TLS peer can trigger an out-of-bounds memcpy that crashes the JVM process.
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 use Netty with the tcnative (BoringSSL/OpenSSL) TLS backend and accept TLS connections from untrusted peers are exposed. Applications using the JDK TLS provider instead of tcnative, or services only reachable by trusted clients, have lower exposure.
No product ranges from the sources yet.
mvn dependency:tree | grep tcnative or gradle dependencies | grep tcnativenetty-tcnative or netty-tcnative-boringssl-static in the lock file or the packaged application2.0.84.Final or laterEach 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 a heap buffer overflow vulnerability in the tcn_write_to_bytebuffer BIO callback caused by failing to wrap the non-application ring buffer write index. Remote TLS peers can drive handshake, renegotiation, or post-handshake messages into this buffer, triggering an out-of-bounds memcpy that crashes the JVM process.
This page as .md · .json · in your agent: get_signal("CVE-2026-116539")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.