netty-tcnative EUVD-2026-109909

Triggering requires non-application bytes (TLS handshake continuation, renegotiation, or TLS 1.3 post-handshake messages) to flow through the custom BIO_java_bytebuffer ring buffer across multiple write/partial-drain cycles WITHOUT the nonApplicationBuffer ever fully emptying, so that offset+length exceeds nonApplicationBufferSize and startIndex underflows. Concretely it depends on the integrating application's choice of a comparatively small nonApplicationBufferSize via SSL.bioNewByteBuffer (e.g. Netty's ReferenceCountedOpenSslEngine) plus attacker-influenced traffic timing - this integrator-dependent requirement is exactly what the CVSS 4.0 AT:P flag encodes and limits reliable exploitation. No authentication is required (PR:N) and no user interaction (UI:N); it is reachable from the peer side of any in-progress or established TLS connection. The flaw is backend-independent (it lives in the generic BIO wrapper, not in OpenSSL/BoringSSL #ifdef branches), so both netty-tcnative and netty-tcnative-boringssl-static are affected.

The assigned CVSS 4.0 base is 8.2 with vector AV:N/AC:L/AT:P/PR:N/UI:N and an availability-only impact (VA:H; VC/VI/VA subsequent all N), i.e. a remote, unauthenticated, no-user-interaction JVM-crash (denial of service). The AT:P flag is the key nuance: exploitation carries an attack requirement beyond the attacker's sole control - per the GHSA root-cause analysis it depends on the integrating application having configured a comparatively small nonApplicationBuffer and on enough non-application bytes cycling through partial drains without the buffer fully emptying. There is NO CISA KEV listing (so not confirmed actively exploited) and NO EPSS score was supplied in the input, so widespread-vs-targeted exploitation probability cannot be quantified here. A public PoC reference exists in the GHSA advisory (a deterministic reproduction via the public JNI/native path); it is not verified in the input as a turnkey wire-level exploit. One material conflict to flag: the vendor GHSA advisory argues CVSS:3.1 C:H/I:H/A:H (claiming a heap-disclosure read primitive and an unbounded heap write), whereas the authoritative input CVSS 4.0 vector scores only availability (VC:N/VI:N/VA:H) and the CVE description states only that it 'crashes the JVM process' - so the demonstrated, agreed impact is reliable DoS, while confidentiality/integrity corruption is described as plausible but not reflected in the assigned score; verify intended impact with the vendor. The vuln.today decision label is 'this_week'. Net: this is a real, patch-this-week priority - a genuine remote unauthenticated DoS reachable through ordinary TLS traffic wherever the library is used - rather than a high-CVSS-but-low-real-risk issue, though absent KEV/EPSS it is not an active-exploitation emergency.

A remote TLS peer connects to a JVM service using netty-tcnative and drives handshake continuation, renegotiation, or TLS 1.3 post-handshake messages so that OpenSSL emits non-application bytes into the internal ring buffer across multiple partial-drain cycles. Because the write-side index is never reduced modulo the buffer size, an integer underflow makes writeChunk negative, producing an out-of-bounds memcpy with a near-SIZE_MAX length that crashes the JVM. The GHSA advisory reports a deterministic reproduction of the underlying arithmetic flaw via the public JNI path, though not a packaged exploit derived purely from wire bytes against a specific integration.