netty-tcnative CVE-2026-116540

Exploitation requires all of: (1) netty-tcnative built/linked against OpenSSL 3.0 or newer - the OPENSSL_VERSION_NUMBER >= 0x30000000L EVP_MAC code path; builds against OpenSSL < 3.0 use HMAC_Init_ex and are NOT affected; (2) TLS session tickets enabled, which is the library's default; and (3) the server operator actively performing in-place session-ticket-key rotation via SSLContext.setSessionTicketKeys0() concurrently with live handshakes - the race cannot occur without an in-flight rotation. The network/handshake side is unauthenticated (PR:N), but the limiting factor is the race window itself: in unmodified code it is only a few CPU instructions wide (lock release to pointer dereference, no I/O between), so reliably landing it in practice needs high rotation frequency combined with high concurrent handshake volume on a busy production server. The only confirmed impact is an availability crash; a confidentiality angle was deliberately excluded by the advisory as unconfirmed.

Signals diverge in severity but agree on mechanism. The input CVSS 4.0 vector scores 8.2 (High), driven entirely by VA:H over a network vector (AV:N/PR:N/UI:N), while the vendor GHSA advisory independently scores CVSS 3.1 at 5.9 (Medium) using AC:H. The apparent conflict is reconciled by the race nature of the bug: the 4.0 vector encodes the timing precondition as AT:P with AC:L, whereas the 3.1 vector folds the narrow nanosecond window into AC:H. Both vectors concur that impact is availability-only - C and I are N - so this is a denial-of-service / memory-corruption crash, not an information-disclosure or RCE issue (the advisory explicitly excludes an unconfirmed confidentiality angle from its score). No EPSS score and no CISA KEV entry are present in the input, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is this_week, not act_now or emergency. Crucially, a remote client cannot unilaterally trigger the flaw: it requires the server operator to be performing in-place session-ticket-key rotation via setSessionTicketKeys0() concurrently with live handshakes, and in unmodified code the window is only a handful of instructions wide. Realistic priority is therefore moderate - a credible DoS against busy servers that rotate ticket keys under load, warranting prompt patching on a normal cadence rather than emergency response.

An unauthenticated remote client repeatedly performs TLS handshakes against a Netty/netty-tcnative server built on OpenSSL 3.x with session tickets enabled (the default) while the operator rotates session-ticket keys under load; if a handshake's ticket callback lands in the gap after the read lock is released but before the stale embedded pointer is dereferenced, the concurrent rotation frees the key array and OpenSSL reads freed HMAC key memory, crashing the process. No standalone weaponized public exploit code is published, but the GHSA advisory documents a hard, repeatable SIGSEGV crash reproduced on the compiled artifact (using race-widening instrumentation to make the genuine nanosecond-scale race deterministically observable).