CVE-2026-116539 in netty-tcnative
Summary
by MITRE • 10/26/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in Netty netty-tcnative prior to version 2.0.84.Final represents a critical memory safety flaw within the TLS implementation layer of the library. Specifically, this issue resides in the tcn_write_to_bytebuffer BIO callback function, which is responsible for handling data transmission during secure communication sessions. The core technical defect stems from an improper management of the non-application ring buffer write index. In standard operation, when writing to a circular or ring buffer, it is imperative that indices are wrapped around to prevent them from exceeding the allocated memory boundaries. However, in this specific implementation, the code fails to perform this wrapping logic correctly under certain conditions. This oversight means that as data continues to be written into the buffer during active TLS sessions, the write index can increment beyond the physical limits of the allocated heap space without being reset or constrained by the buffer size.
This memory corruption vulnerability is classified as a Heap Buffer Overflow according to Common Weakness Enumeration standards, specifically aligning with CWE-120. The operational impact is severe because it allows remote attackers to trigger an out-of-bounds memcpy operation. By sending crafted TLS handshake messages, renegotiation requests, or post-handshake data, an attacker can manipulate the flow of information into this vulnerable buffer. When the write index exceeds the allocated heap memory due to the missing wrap logic, subsequent copy operations will read from or write to adjacent memory regions that do not belong to the intended buffer structure. This results in immediate corruption of surrounding memory structures within the Java Virtual Machine process space.
The consequence of triggering this vulnerability is typically a crash of the JVM process, leading to a denial of service against any application relying on netty-tcnative for TLS termination or initiation. While heap overflows can sometimes be exploited for arbitrary code execution through sophisticated techniques such as heap spraying or structure overwrite attacks, in the context of managed languages like Java running within a VM, the immediate and most reliable outcome is process instability and termination. This aligns with ATT&CK technique T1499 Endpoint Denial of Service, where an adversary disrupts availability by exhausting resources or crashing services. The vulnerability affects both client-side connections initiated by applications using this library and server-side TLS endpoints that accept incoming connections from remote peers capable of driving the specific message sequences required to trigger the overflow condition during handshake renegotiation phases.
Mitigation for this issue requires upgrading netty-tcnative to version 2.0.84.Final or later, where the developers have implemented proper bounds checking and index wrapping logic within the tcn_write_to_bytebuffer callback. Organizations should audit their dependency trees to ensure that no legacy versions of this library are present in production environments. Additionally, implementing network-level rate limiting on TLS renegotiation requests can provide a layer of defense-in-depth against potential exploitation attempts while patching is being deployed. Security teams should also monitor for unusual JVM crashes or out-of-memory errors associated with netty-tcnative processes as indicators of compromise during the transition period to the patched version.