netty-tcnative EUVD-2026-109912

The library-level corruption is unconditional and affects all backends (OpenSSL-dynamic, BoringSSL-static, LibreSSL) at versions <= 2.0.83.Final, triggered by any remote client placing 0xC0 0x80 in the ClientHello server_name - no special server configuration or authentication is required to reach the vulnerable NewStringUTF path. Security IMPACT, however, is gated on the integrating application actually relying on the SNI hostname for a trust decision: specifically (a) using a SniHostNameMatcher or SSL.getSniHostname() for certificate/virtual-host selection, routing, or access control, and/or (b) downstream logic that re-encodes the hostname to standard UTF-8 (reintroducing a literal 0x00) or passes it to NUL-sensitive native/C, file-path, or logging consumers. Applications that do not use SNI-based matching or that treat the hostname as opaque are not meaningfully exposed. The limiting factors are therefore application behavior and affected version, not attacker reachability.

This is a genuine but moderate-priority issue, not a top-tier emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) and the vendor GHSA CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, 6.5 Medium) agree: the flaw is remotely reachable, requires no authentication (PR:N) and no user interaction, and is deterministically triggerable by any TLS client via the ClientHello. However, impact is rated Low/Low because the confidentiality and integrity consequences are contingent on how the integrating application consumes the SNI hostname downstream - the library unconditionally manufactures the embedded-NUL string, but whether that leads to an access-control bypass, hostname spoofing, or log/truncation injection depends on application code. No EPSS score and no KEV listing were provided, and there is no public exploit reference in the input, so there is no signal of active or widespread exploitation. The vuln.today decision label is 'this_month,' consistent with a patch-on-normal-cadence posture rather than act_now/emergency. Note the CWE disagreement: NVD lists CWE-176 (improper Unicode encoding handling) while the vendor GHSA cites CWE-20/CWE-172/CWE-838 - a classification nuance, not a conflict in mechanism.

A remote unauthenticated client opens a TLS connection to a netty-tcnative-backed server and sends a ClientHello whose server_name extension embeds the modified-UTF-8 overlong sequence 0xC0 0x80. OpenSSL's own embedded-NUL check passes it through, but JNI NewStringUTF() decodes those bytes into a genuine U+0000 inside the Java hostname string handed to SniHostNameMatcher.match() and SSL.getSniHostname(). If the application uses that hostname for certificate/virtual-host selection, routing, logging, or access decisions, the attacker can confuse those decisions or inject a truncated hostname downstream. The reporter (VulnCheck) reproduced the library-level corruption deterministically (3/3), but no public weaponized exploit is referenced.