---
id: "CVE-2026-116542"
kind: "vulnerability"
aliases: ["CVE-2026-116542"]
title: "Netty tcnative: overlong SNI bytes spoof hostnames during TLS handshake"
severity: "medium"
cvss: 6.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["java", "netty", "package", "sni", "tls"]
not_affected_if: ["jdk-ssl-provider", "no-sni-logic"]
published_at: "2026-10-26T16:17:19+00:00"
first_seen_at: "2026-10-26T16:31:01+00:00"
updated_at: "2026-10-26T16:32:58+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116542", "first_seen_at": "2026-10-26T16:31:01+00:00"}]
---

# Netty tcnative: overlong SNI bytes spoof hostnames during TLS handshake

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.

_Summary, check and fix written by a model from the sources; labelled as such._

## 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.
- 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.
- Rebuild and redeploy the service after the dependency bump.

## Timeline

- 2026-10-26T16:31:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-116542

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_