netty-tcnative EUVD-2026-109911

Exploitation requires netty-tcnative at or below 2.0.83.Final and a TLS 1.3 session, and specifically requires the internal side buffer (nonApplicationBuffer, populated by queued post-handshake records like NewSessionTicket, KeyUpdate, or alerts) to be non-empty at the moment tcn_write_to_bytebuffer runs in write-sink mode; when that coincidence occurs the BIO_write return value is inflated by the side-buffer flush count. No malformed input or protocol violation from the peer is needed - standard TLS 1.3 message flow is sufficient (PR:N, unauthenticated remote). Limiting factors: outcome is backend-specific - on BoringSSL it causes silent handshake/data corruption, and the unconditional process abort path additionally requires a completed handshake (post-handshake write); on LibreSSL it permanently wedges that connection's write path. The required coincidence of queued side-buffer data with a write-mode BIO_write is what the CVSS 4.0 AT:P (attack requirement present) encodes.

Multiple signals converge on a genuine priority rather than an inflated CVSS. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H, 8.2) describes an unauthenticated, network-reachable availability flaw whose exploitation carries an attack requirement (AT:P) - the internal side buffer must be non-empty at the moment of a write-mode BIO_write, a state produced by normal TLS 1.3 post-handshake traffic rather than attacker-malformed input. Note a real conflict in the inputs: the vulnerability-database CVSS 4.0 records VI:N/VA:H (availability only), while the GHSA advisory's CVSS 3.1 records C:N/I:H/A:L (integrity-dominant). This is not a scoring error so much as backend divergence - BoringSSL yields silent handshake/data corruption (integrity) or an unconditional JVM abort (availability), whereas LibreSSL yields a permanently wedged connection (availability); both characterizations are defensible. There is no CISA KEV listing (so not confirmed actively exploited) and no EPSS score was supplied, so widespread opportunistic exploitation is unproven. However, VulnCheck's GHSA advisory includes dynamically-confirmed reproduction code, the mechanism is well understood, a remote peer can provoke it without authentication, and the vuln.today decision label is this_week with a vendor patch available. Net: a real, promptly-patchable issue - remote unauthenticated DoS (and possible silent TLS-stream corruption) - that warrants scheduled urgency, not emergency-grade panic, absent evidence of in-the-wild use.

A remote TLS 1.3 peer connects to a Java service using netty-tcnative (≤2.0.83.Final) and provokes queued post-handshake records such as NewSessionTicket or KeyUpdate, leaving the internal side buffer non-empty when a write-mode BIO_write occurs. The resulting BIO_write return-value over-count truncates the TLS flight and either silently corrupts the data placed on the wire (BoringSSL), permanently wedges the connection (LibreSSL), or aborts the JVM process via BoringSSL's SSLBuffer::Consume(). A working PoC reference exists in the GHSA advisory, including a BoringSSL build that dynamically confirmed both the over-count and downstream handshake corruption.