{"id":"CVE-2026-116542","kind":"vulnerability","aliases":["CVE-2026-116542"],"related":[],"title":"Netty tcnative: overlong SNI bytes spoof hostnames during TLS handshake","description":"Netty netty-tcnative before 2.0.84.Final contains an SNI hostname spoofing vulnerability that allows remote unauthenticated clients to alter hostnames via JNI NewStringUTF decoding. Attackers can send overlong encodings like 0xC0 0x80 in the ClientHello server_name to confuse SNI-based certificate selection, access decisions, and logging.","summary":"netty-tcnative before 2.0.84.Final decodes the TLS ClientHello server_name field with JNI NewStringUTF, which accepts overlong UTF-8 encodings such as 0xC0 0x80. A remote unauthenticated client can therefore present a hostname that differs from what it sent, confusing SNI-based certificate selection, access decisions and logs.","severity":"medium","cvss":6.9,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["java","netty","package","sni","tls"],"not_affected_if":["jdk-ssl-provider","no-sni-logic"],"how_to_check":"- Look for `io.netty:netty-tcnative` or `netty-tcnative-boringssl-static` in the dependency tree (for example `mvn dependency:tree` or `gradle dependencies`) and note the version.\n- Confirm whether the service uses SNI-based certificate or routing decisions with OpenSSL/BoringSSL via tcnative.","fix":"- Upgrade `io.netty:netty-tcnative` (and the netty-tcnative-boringssl-static artifact) to `2.0.84.Final` or later.\n- Rebuild and redeploy the service after the dependency bump.","status":"open","published_at":"2026-10-26T16:17:19+00:00","first_seen_at":"2026-10-26T16:31:01+00:00","triaged_at":"2026-10-26T16:32:58+00:00","updated_at":"2026-10-26T16:32:58+00:00","category":"package","confidence":0.6,"triage":{"at":"2026-10-26T16:32:58Z","model":"claude-haiku-5-5","output":{"fix":"- Upgrade `io.netty:netty-tcnative` (and the netty-tcnative-boringssl-static artifact) to `2.0.84.Final` or later.\n- Rebuild and redeploy the service after the dependency bump.","reach":"internet","title":"Netty tcnative: overlong SNI bytes spoof hostnames during TLS handshake","impact":"medium","summary":"netty-tcnative before 2.0.84.Final decodes the TLS ClientHello server_name field with JNI NewStringUTF, which accepts overlong UTF-8 encodings such as 0xC0 0x80. A remote unauthenticated client can therefore present a hostname that differs from what it sent, confusing SNI-based certificate selection, access decisions and logs.","category":"package","nicknames":[],"who_cares":["java","netty","tls","sni"],"confidence":0.6,"needs_auth":"no","worst_case":"Attacker spoofs hostnames, redirecting certificate choice and access decisions","analyst_note":"Check the NVD entry and the Netty GitHub advisory for the exact affected artifacts, the tcnative SSL providers involved, and whether a proof of concept or CVSS vector confirms the attack conditions.","how_to_check":"- Look for `io.netty:netty-tcnative` or `netty-tcnative-boringssl-static` in the dependency tree (for example `mvn dependency:tree` or `gradle dependencies`) and note the version.\n- Confirm whether the service uses SNI-based certificate or routing decisions with OpenSSL/BoringSSL via tcnative.","needs_analyst":true,"not_affected_if":["jdk-ssl-provider","no-sni-logic"],"who_is_affected":"Java services that terminate TLS through Netty with the native tcnative (OpenSSL or BoringSSL) SSL provider and rely on SNI hostnames to pick certificates, route requests or make access decisions. Services using the JDK SSL provider or no SNI-dependent logic are less exposed. unknown whether the sources list specific affected deployment patterns beyond this.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"medium"},"cost_usd":0.000714,"input_tokens":3354,"output_tokens":757,"severity_before":"medium"},"analyst_status":null,"analyst_note":null,"search":"'-116542':13A,16A '-2026':12A,15A '-8':41B '0x80':46B,103C '0xc0':45B,102C '2.0.84.final':26B,77C 'accept':38B 'access':68B,116C 'allow':85C 'alter':90C 'attack':96C 'base':65B,113C 'byte':5A 'certif':66B,114C 'client':50B,88C 'clienthello':30B,106C 'confus':62B,110C 'contain':78C 'cve':11A,14A 'decis':69B,117C 'decod':27B,95C 'differ':57B 'encod':42B,100C 'field':33B 'handshak':10A 'hostnam':7A,55B,81C,91C 'java':17B 'jni':35B,93C 'like':101C 'log':71B,119C 'name':32B,108C 'netti':1A,18B,23B,72C,74C 'netty-tcn':22B,73C 'newstringutf':36B,94C 'overlong':3A,39B,99C 'packag':19B 'present':53B 'remot':48B,86C 'select':67B,115C 'send':98C 'sent':61B 'server':31B,107C 'sni':4A,20B,64B,80C,112C 'sni-bas':63B,111C 'spoof':6A,82C 'tcnativ':2A,24B,75C 'therefor':52B 'tls':9A,21B,29B 'unauthent':49B,87C 'utf':40B 'via':92C 'vulner':83C","nicknames":[],"mitigations":[],"who_affected":"Java services that terminate TLS through Netty with the native tcnative (OpenSSL or BoringSSL) SSL provider and rely on SNI hostnames to pick certificates, route requests or make access decisions. Services using the JDK SSL provider or no SNI-dependent logic are less exposed. unknown whether the sources list specific affected deployment patterns beyond this.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-26T16:17:19+00:00","kev":null,"cvss_vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","cvss_by":"disclosure@vulncheck.com","poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-116542","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-116542","severity":null,"published_at":"2026-10-26T16:17:19+00:00","modified_at":"2026-10-26T16:17:19+00:00","first_seen_at":"2026-10-26T16:31:01+00:00","fetched_at":"2026-10-26T16:31:01+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}