CVE-2026-100665

Executive Summary

CVE-2026-100665 is an incomplete hostname verification vulnerability in Netty's QUIC certificate verification path, affecting versions from 4.2.11.Final before 4.2.18.Final. When applications use a plain X509TrustManager, the BoringSSLCertificateVerifyCallback discards the SSLEngine, preventing endpoint identification from executing even when HTTPS verification is explicitly configured. A network-positioned attacker can present a valid certificate chain issued for a different hostname that the plain trust manager accepts, bypassing hostname authentication for QUIC clients and enabling adversary-in-the-middle interception.

Technical Analysis

The vulnerability resides in Netty's QUIC implementation and its integration with BoringSSL-based certificate verification. QUIC (Quick UDP Internet Connections) performs TLS 1.3 handshakes over UDP, and Netty delegates certificate chain validation and hostname verification to a trust manager component. In the affected versions, the BoringSSLCertificateVerifyCallback class handles the verification callback invoked during the TLS handshake.

The core defect is a logic error in how the callback propagates the verification context. When the configured trust manager is a plain X509TrustManager — as opposed to Netty's own enhanced trust manager implementations that carry endpoint identification context — the callback discards the associated SSLEngine. The SSLEngine is the object that carries the endpoint identification algorithm setting (typically HTTPS) and the target hostname. By discarding it, the callback prevents endpoint identification from running during the handshake.

This is a classic instance of CWE-295 (Improper Certificate Validation). The trust manager still validates the certificate chain cryptographically — it confirms the chain is signed by a trusted CA, is within its validity period, and otherwise well-formed. What it fails to do is confirm that the certificate's subject alternative names (SANs) or common name match the hostname the client intended to reach. The result is that a certificate issued for attacker.example.com by a trusted CA will be accepted by a client attempting to connect to victim.example.com.

The incomplete fix history is significant: the description states this defect exists "from 4.2.11.Final," implying an earlier attempt to address hostname verification in the QUIC path did not fully cover the plain X509TrustManager case. This is a recurring pattern in TLS verification fixes — coverage gaps between different trust manager implementations.

Attack surface considerations:

• Protocol: QUIC over UDP (typically UDP/443)
• Precondition: the client uses a plain X509TrustManager rather than a Netty-managed trust manager that carries endpoint identification context
• Attacker position: network path (on-path / MITM), requiring no authentication or user interaction
• Impact: loss of confidentiality (C:H) — the client believes it is communicating with the intended server but is instead communicating with the attacker

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N reflects a remotely exploitable, low-complexity, unauthenticated confidentiality breach with no integrity or availability impact. The absence of an integrity impact in the vector is consistent with a MITM that transparently relays or observes traffic rather than modifying it.

Insufficient technical detail is available regarding the exact code path and the precise diff that constitutes the fix in 4.2.18.Final; the analysis above is derived strictly from the NVD description.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-295 incomplete hostname verification) and the described mechanism.

1) Reconnaissance / target identification An attacker positioned on the network path (same LAN segment, compromised router, hostile Wi-Fi access point, or an upstream network position capable of intercepting UDP traffic) identifies victim clients that use Netty's QUIC stack with a plain X509TrustManager. This can be inferred from observing QUIC traffic patterns, application fingerprints, or knowledge of the target's software stack.

2) Triggering the flaw The attacker intercepts or races the QUIC handshake to victim.example.com. During the TLS 1.3 handshake carried over QUIC, the attacker presents a certificate chain that is cryptographically valid — issued by a CA the client trusts — but registered for a hostname the attacker controls, not victim.example.com. Because BoringSSLCertificateVerifyCallback discards the SSLEngine for plain X509TrustManager configurations, the endpoint identification step never runs. The plain trust manager validates only chain trust and validity, not hostname correspondence, and accepts the attacker's certificate.

3) Payload / execution method Once the handshake completes, the attacker terminates the QUIC/TLS session and acts as a transparent or terminating proxy. Hostname authentication has been bypassed; the client proceeds as though it has reached the legitimate endpoint. At the vulnerability-class level, this is an adversary-in-the-middle interception enabled by missing hostname binding of the certificate. No specific injected payload or code-execution primitive is described; the technique is credential/session interception and traffic observation.

4) Post-exploitation impact The attacker can read traffic the client believes is protected to the legitimate server, including credentials, tokens, and application data (confidentiality impact, C:H). Depending on application behavior, the attacker may also serve substituted content. Per the CVSS vector, there is no direct integrity or availability impact attributed, but downstream data exposure and session compromise are the primary concerns.

Impact Assessment

Business impact centers on compromised confidentiality for any application that uses Netty's QUIC client with a plain X509TrustManager and relies on HTTPS-style endpoint identification for security. Affected systems include JVM-based clients, services, and embedded Netty consumers that have adopted the QUIC transport introduced in the 4.2.x line.

Blast radius: any QUIC client connection from an affected Netty build is potentially interceptable by an on-path attacker without authentication or user interaction (PR:N/UI:N). The high confidentiality subscore (C:H) reflects that a successful MITM exposes all application-layer data in the session. The integrity (I:N) and availability (A:N) subscores of zero indicate the vulnerability itself does not grant data modification or denial-of-service — though a MITM relay could introduce secondary effects outside the scope of this CVE.

Because the flaw is a coverage gap in hostname verification rather than a total absence of certificate validation, the attacker must still obtain a CA-trusted certificate for a different name. This raises the bar slightly compared to a null-verification bug but is well within reach of a resourced adversary (free or low-cost DV certificates, subdomain takeover, or a compromised intermediate).

CISA KEV status is NO and no exploit code is publicly available, so immediate mass exploitation is not indicated. However, the low attack complexity and network-only precondition make targeted MITM attacks plausible against high-value QUIC clients.

Detection Guidance

Sigma Rule

title: Netty QUIC Client Certificate Hostname Verification Bypass
id: 8f2c1a44-9d3e-4b77-a0c2-6e5f1b2d9c10
status: experimental
description: Detects JVM processes loading Netty QUIC classes with plain X509TrustManager configuration, indicating exposure to CVE-2026-100665
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-100665
author: valtersit.com
date: 2026/01/01
logsource:
  category: process_access
  product: windows
detection:
  selection_netty:
    TargetImage|endswith: '\java.exe'
    CallTrace|contains:
      - 'io.netty'
      - 'BoringSSLCertificateVerifyCallback'
  selection_quic:
    CallTrace|contains:
      - 'Quic'
      - 'QUIC'
  condition: selection_netty and selection_quic
falsepositives:
  - Legitimate Netty QUIC clients that configure an enhanced trust manager
level: medium
tags:
  - attack.t1557
  - cwe.295

YARA Rule

rule CVE_2026_100665_Netty_QUIC_Hostname_Verification
{
    meta:
        description = "Detects Netty QUIC certificate verification classes associated with CVE-2026-100665"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100665"
        date = "2026-01-01"

    strings:
        $cls1 = "BoringSSLCertificateVerifyCallback" ascii wide
        $cls2 = "X509TrustManager" ascii wide
        $quic = "io/netty/incubator/codec/quic" ascii wide
        $endpoint = "endpointIdentificationAlgorithm" ascii wide

    condition:
        (uint16(0) == 0xCAFE or uint32(0) == 0xBEBAFECA) and
        $cls1 and $cls2 and ($quic or $endpoint)
}

Suricata IDS Rule

alert udp any any -> any 443 (msg:"CVE-2026-100665 Netty QUIC potential hostname verification bypass - certificate for mismatched hostname"; flow:to_server; content:"|01 00|"; depth:2; byte_test:1,=,0x03,0; threshold:type limit, track by_src, count 1, seconds 60; reference:cve,2026-100665; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-100665; classtype:attempted-recon; sid:2026100665; rev:1;)

Elastic Detection

// Detect JVM processes loading Netty QUIC verification classes on affected versions
process where process.name in ("java", "java.exe") and
  process.command_line like~ "*netty*" and
  (dll.path like~ "*netty*quic*" or dll.name like~ "*netty*") and
  process.parent.name in ("java", "java.exe", "systemd", "bash")

Splunk SPL Query

index=network sourcetype=quic OR sourcetype=zeek_quic
| where transport == "quic"
| stats count earliest(_time) as first_seen latest(_time) as last_seen
    values(dest_ip) as dest_ips by src_ip
| where count > 0
| join type=left src_ip
    [ search index=app sourcetype=java_jvm_logs
      | search "BoringSSLCertificateVerifyCallback" OR "X509TrustManager" OR "io.netty.incubator.codec.quic"
      | fields src_ip, host ]
| table src_ip host dest_ips count first_seen last_seen
| sort - count

Wazuh OSSEC Rule

<group name="netty,cve-2026-100665,">
  <rule id="100665" level="10">
    <decoded_as>json</decoded_as>
    <field name="class">BoringSSLCertificateVerifyCallback</field>
    <description>CVE-2026-100665: Netty QUIC certificate verification callback invoked with plain X509TrustManager - possible hostname verification bypass</description>
    <mitre>
      <id>T1557</id>
    </mitre>
    <group>cwe_295,</group>
  </rule>
  <rule id="100666" level="8">
    <if_sid>100665</if_sid>
    <field name="trustManager">X509TrustManager</field>
    <description>CVE-2026-100665: Plain X509TrustManager detected in Netty QUIC path - endpoint identification may not run</description>
    <group>cwe_295,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1) Immediate mitigations

• Where feasible without verifying vendor code changes, avoid relying on plain X509TrustManager for QUIC clients. Note that the vulnerability description indicates endpoint identification is skipped specifically for plain trust managers; any configuration change must be validated in a test environment against the 4.2.18.Final behavior before production rollout.
• Restrict network paths: QUIC runs over UDP; apply egress/ingress filtering and monitor for UDP-based MITM indicators. Where QUIC is not required, disable it and fall back to TCP-based TLS, which is handled by a different verification path.
• Enforce certificate pinning at the application layer where possible, independent of the Netty trust manager path, so that a mismatched-hostname certificate is rejected even if endpoint identification is skipped.

2) Patch / upgrade steps

• Upgrade Netty to 4.2.18.Final or later. The NVD description states the issue affects versions from 4.2.11.Final before 4.2.18.Final, making 4.2.18.Final the first fixed release per the provided data.
• Verify the upgrade with a dependency scan (mvn dependency:tree, Gradle dependencies, or an SCA tool) to confirm no transitive older Netty 4.2.x QUIC artifacts remain.
• After upgrading, validate hostname verification behavior by connecting a QUIC client to a host presenting a certificate for a different name and confirming the handshake is rejected.

3) Long-term hardening

• Prefer Netty trust manager implementations that carry endpoint identification context over plain X509TrustManager for QUIC, once confirmed against the vendor's fixed code.
• Add regression tests to CI that assert hostname mismatch rejection for QUIC clients, so future incomplete verification fixes are caught.
• Track Netty release notes and security advisories continuously; subscribe to the vendor's disclosure channels.

References

• NVD — CVE-2026-100665: https://nvd.nist.gov/vuln/detail/CVE-2026-100665
• CWE-295 — Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html
• MITRE ATT&CK T1557 — Adversary-in-the-Middle: https://attack.mitre.org/techniques/T1557/
• Netty project (release notes / 4.2.x line): https://netty.io/news/
• FIRST EPSS: not yet scored for this CVE as of this report — monitor https://api.first.org/data/v1/epss?cve=CVE-2026-100665

No public PoC, exploit code, or threat-actor campaign has been identified for CVE-2026-100665 in the available data. CISA KEV status is NO.