CVE-2026-116540 in netty-tcnative
Summary
by MITRE • 10/26/2026
netty-tcnative 2.0.66.Final before 2.0.84.Final built against OpenSSL 3.x contains a use-after-free vulnerability in ssl_tlsext_ticket_key_cb during session ticket key rotation. Remote clients performing TLS handshakes while setSessionTicketKeys0 frees the shared key array cause OpenSSL to read freed HMAC keys, crashing or corrupting ticket processing.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in netty-tcnative versions 2.0.66.Final through 2.0.83.Final when built against OpenSSL 3.x represents a critical memory safety flaw rooted in improper synchronization during cryptographic key management operations. Specifically, the defect resides within the ssl_tlsext_ticket_key_cb callback function, which is responsible for handling TLS session ticket encryption and decryption. This component plays a pivotal role in maintaining stateful sessions across TCP connections by allowing clients to resume previous interactions without performing full handshakes, thereby improving performance and reducing latency. The core technical flaw involves a race condition that occurs during the rotation of these shared symmetric keys used for HMAC-based message authentication codes within session tickets.
When an application invokes setSessionTicketKeys0 to rotate or update the active encryption keys, it triggers a process where the old key array is deallocated while potentially still being referenced by ongoing TLS handshake operations initiated by remote clients. If a client performs a TLS handshake at precisely this moment of transition, OpenSSL attempts to access the previously allocated memory region containing the HMAC keys for verifying session ticket integrity. Because the underlying C library has already freed this memory block due to the key rotation process completing ahead of the handshake completion, the application engages in an out-of-bounds read operation on a dangling pointer. This constitutes a classic use-after-free vulnerability where the program continues to operate with invalid memory references after that memory has been returned to the system allocator.
The operational impact of this flaw is severe and multifaceted. The immediate consequence is typically a segmentation fault or application crash, leading to a denial-of-service condition for services relying on netty-tcnative for high-performance TLS termination. In more sophisticated attack scenarios where an attacker can control the contents of the freed memory region through heap spraying techniques, this vulnerability could potentially be leveraged to achieve arbitrary code execution. The corruption of ticket processing logic also undermines the integrity guarantees provided by TLS session tickets, potentially allowing attackers to forge or manipulate session identifiers if they can predict or influence the state of the cryptographic material before it is fully invalidated and replaced.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, which describes situations where pointers are used after their memory has been freed, leading to undefined behavior. It also intersects with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition), as the root cause is a lack of proper locking or atomicity guarantees around the key rotation and handshake verification processes. In terms of adversary tactics, this flaw could be exploited within the MITRE ATT&CK framework under techniques related to Denial of Service or potentially Initial Exploitation if code execution is achieved via heap exploitation primitives available in modern OpenSSL implementations.
Mitigation strategies must prioritize immediate version upgrades as the primary defense vector. Organizations running affected versions should upgrade netty-tcnative to 2.0.84.Final or later, where this race condition has been resolved through improved synchronization mechanisms that ensure key rotation is atomic with respect to ongoing handshake operations. Until an upgrade can be performed, administrators may consider disabling session ticket resumption entirely by configuring the SSL context to not offer tickets, thereby removing the attack surface associated with ssl_tlsext_ticket_key_cb. Additionally, deploying runtime protection tools such as Address Sanitizer in development environments or memory-safe wrappers in production can help detect and prevent exploitation attempts of similar heap-based vulnerabilities across the infrastructure.