CVE-2026-100659

Executive Summary

CVE-2026-100659 is a request-smuggling-class parsing flaw (CWE-444) in Netty's HTTP/3 codec (io.netty:netty-codec-http3) affecting versions 4.2.0.Final through 4.2.17.Final. The codec fails to enforce RFC 9114's requirement that the :authority pseudo-header and a literal host header, when both are present in a single HEADERS frame, must carry the same value; a remote, unauthenticated peer can submit conflicting values and the request is accepted and forwarded to the application with two divergent authorities. Organizations running Netty-based HTTP/3 front ends, gateways, or proxies where different components in the request path consult different headers for routing, virtual-host selection, or access control are at risk of those decisions being bypassed.

Technical Analysis

HTTP/3 (RFC 9114) is the third major version of HTTP, running over QUIC (RFC 9000). In HTTP/3, request metadata is transmitted as QPACK-encoded header fields inside HEADERS frames. HTTP/2 and HTTP/3 define pseudo-header fields — including :authority (the logical equivalent of HTTP/1.1's Host header) — alongside regular header fields such as host.

RFC 9114 requires that when a request contains both the :authority pseudo-header field and a literal host header field, the two must contain the same value. This is a security-relevant interoperability constraint: it exists precisely to prevent the two fields from being interpreted inconsistently by different components in a request-processing chain.

Netty's HTTP/3 codec in versions 4.2.0.Final through 4.2.17.Final does not enforce this requirement. Per the NVD description, a remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values. The codec accepts this and delivers the request to the application with two conflicting authorities.

The core security problem is a parser differential / authority confusion condition:

• The application-layer code within Netty's codec does not normalize or reconcile the two authority sources.
• Downstream components in a request path — for example, a reverse proxy, load balancer, API gateway, service mesh sidecar, or the application framework itself — may each independently choose which field to trust.
• A security control (virtual-host routing rule, allow/deny ACL, tenant-isolation check, WAF rule) that consults the :authority pseudo-header may permit the request, while an upstream or downstream component that routes or authorizes on the literal host header may direct it elsewhere — or vice versa.

This class of bug is closely related to the well-known "host header confusion" family and to HTTP request smuggling/desync issues (CWE-444). Unlike classic request smuggling — where one component sees different request boundaries than another — here the mismatch is in which authority the request claims to belong to, which is nonetheless an access-control bypass primitive when security decisions are made on the divergent fields.

The CWE-444 classification reflects the general category of inconsistent interpretation of HTTP request structures between two or more components. CVSS scores it as a network-reachable, low-complexity, unauthenticated issue with low confidentiality and integrity impact and no availability impact.

Code-level detail beyond the above is not derivable from the available data. Specifically, the exact class or method within io.netty-codec-http3 that performs (or omits) the validation, and the exact internal reconciliation logic, are not described in the NVD text or CNA title. Those details should not be assumed.

Exploitation Scenarios

The attack chain for this vulnerability is inferred from the vulnerability class (authority confusion via dual-header inconsistency); no public proof-of-concept or exploit code is available per the provided data.

1. Reconnaissance / target identification. An attacker identifies a target service that terminates or forwards HTTP/3 traffic through Netty 4.2.0.Final–4.2.17.Final. This may be a CDN edge, a reverse proxy, an API gateway, a service-mesh ingress, or any Java HTTP/3 server built on the affected Netty codec. The attacker needs only network reachability to the HTTP/3 (QUIC) endpoint — no credentials. Reconnaissance may include probing for HTTP/3 support via Alt-Svc advertisements or direct QUIC connection attempts.

2. Triggering the flaw. The attacker establishes a QUIC connection and sends an HTTP/3 request whose single HEADERS frame contains both the :authority pseudo-header field and a literal host header field, with different values under the attacker's control. Because the Netty codec (in the affected range) does not enforce that the two match, the request is accepted rather than rejected as malformed.

3. Delivery to the application with conflicting authorities. The request is delivered downstream carrying two inconsistent authority values. The attacker selects values so that different components consult different fields. For example, the value in one field may match a target the front-end is configured to route or permit, while the other value names a different virtual host or tenant that a downstream service trusts.

4. Post-exploitation impact. Depending on the deployment, the divergence allows:

   • Routing bypass — traffic intended for (or restricted to) one virtual host is directed to another.
   • Virtual-host / tenant isolation bypass — a request is treated as belonging to a host/tenant the attacker is not authorized to reach, potentially reaching internal-only hosts.
   • Access-control decision bypass — an ACL, WAF rule, or authorization check that keys on one field is satisfied while the effective request is served under the other field's identity.

   This is a security-control bypass primitive, not remote code execution. Impact is bounded to low confidentiality and low integrity per the CVSS vector (C:L/I:L), with no availability impact and no scope change (S:U). The precise impact is highly deployment-dependent: services that normalize headers or that reject mismatched authorities at a later layer will not be exploitable.

No attack tooling, exploit code, or in-the-wild campaign for this CVE is known from the provided data.

Impact Assessment

Confidentiality (C:L): An attacker may be able to access resources or content associated with an authority value they would not normally be authorized to use, when a component in the path trusts the attacker-controlled field. This is rated Low because exposure is limited to what the misrouted/mis-authorized request can reach, not bulk data compromise.

Integrity (I:L): Requests may be processed against the wrong virtual host, tenant, or policy, potentially allowing state changes within resources the attacker reaches via the confusion. Rated Low for the same bounded-reach reason.

Availability (A:N): The flaw involves header validation and routing decisions, not resource exhaustion or processing disruption; no availability impact is assessed.

Attack Vector / Complexity / Privileges / User Interaction: Network (AV:N), Low complexity (AC:L), no privileges (PR:N), no user interaction (UI:N). The attack requires only the ability to reach the service and craft a HEADERS frame — trivially within reach of any remote peer with QUIC access.

Scope (S:U): Impact is assessed as confined to the vulnerable component's security authority; the CVSS base vector does not indicate scope change.

Blast radius. Any Netty-based HTTP/3 endpoint in the affected version range where (a) both :authority and host are consumed downstream and (b) a security-relevant decision (routing, virtual host, ACL) keys on one field while another component acts on the other. Multi-tier architectures with heterogeneous front-end and application-layer header handling have the widest exposure. Environments that terminate HTTP/3 directly in Netty, use virtual-host routing, or enforce tenant isolation at the HTTP layer are the highest priority.

Overall CVSS base score: 6.5 (Medium), consistent with a remotely exploitable access-control/routing bypass carrying limited, deployment-dependent impact.

Detection Guidance

Detection is inherently difficult because, at the wire level, the exploitation traffic is a syntactically well-formed HTTP/3 request; only the semantic conflict between :authority and host reveals malicious intent. Detection should focus on (1) logging when both fields are present and disagree, and (2) application/infrastructure logs where requests are served under one authority while authenticating/routing on another. The rules below are provided as defensive starting points and may require tuning to the environment; because HTTP/3/QPACK-level inspection is not broadly supported by signature engines, some rules approximate the condition via proxy/gateway logs at the HTTP layer.

Sigma Rule

title: HTTP/3 Request with Conflicting :authority and Host Header Fields (CVE-2026-100659)
id: 7f3a1c2e-1006-59a9-b1de-000000000001
status: experimental
description: Detects requests where the :authority pseudo-header and the literal host header carry different values, the condition being exploited in Netty HTTP/3 codec versions 4.2.0.Final-4.2.17.Final.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-100659
author: Valters IT Threat Intelligence
date: 2026/01/01
logsource:
  category: webserver
detection:
  selection_authority:
    authority|exists: true
  selection_host:
    host|exists: true
  condition: selection_authority and selection_host and authority != host
fields:
  - client_ip
  - authority
  - host
  - uri
falsepositives:
  - Misconfigured clients that legitimately send a Host header differing from :authority
  - Legitimate proxy rewrites
level: medium

YARA Rule

rule CVE_2026_100659_HTTP3_Authority_Host_Conflict
{
    meta:
        description = "Detects HTTP/3 HEADERS payloads containing both :authority and host fields, indicative of authority-confusion attempts against Netty HTTP/3 codec (CVE-2026-100659)"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100659"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $authority = ":authority" ascii wide nocase
        $host      = "host" ascii wide nocase

    condition:
        uint16(0) == 0x0000 and all of them
}

Note: this is a low-fidelity content signature; legitimate HTTP/3 traffic frequently contains both :authority and host. Pair with log-based correlation (see Sigma rule) to reduce false positives.

Suricata IDS Rule

alert http3 any any -> any any (msg:"CVE-2026-100659 Possible Netty HTTP/3 authority/host header conflict"; flow:established,to_server; content:":authority"; http_header; content:"host"; http_header; reference:cve,2026-100659; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-100659; classtype:attempted-recon; sid:1006590; rev:1;)

Note: HTTP/3/QUIC header inspection support varies across Suricata builds; deploy as a best-effort signature and supplement with proxy-layer logging. The rule flags the presence of both header fields and should be correlated with value mismatch at the log layer.

Elastic Detection

sequence by source.ip with maxspan=5s
  [ network where network.transport == "quic" and http.request.method != null ]

The above EQL selects HTTP/3/QUIC request events. Where decoded header fields (http.request.headers.authority, http.request.headers.host) are available in your Elastic ingestion pipeline, add the mismatch predicate:

any where network.transport == "quic"
  and http.request.headers.authority != null
  and http.request.headers.host != null
  and http.request.headers.authority != http.request.headers.host

Splunk SPL Query

index=web_or_proxy sourcetype IN ("http3","netty","quic")
| eval authority=coalesce(authority, ":authority", http_request_authority)
| eval hosthdr=coalesce(host, host_header, http_request_host)
| where isnotnull(authority) AND isnotnull(hosthdr) AND authority != hosthdr
| stats count values(uri) as uris by clientip, authority, hosthdr
| sort - count

Wazuh OSSEC Rule

<group name="web,cve-2026-100659,">
  <rule id="100659" level="10">
    <decoded_as>json</decoded_as>
    <field name="authority">\.+</field>
    <field name="host">\.+</field>
    <description>CVE-2026-100659: HTTP/3 request with conflicting :authority and host header fields</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Note: Wazuh does not natively compare two JSON fields within a single rule expression. To detect the mismatch precisely, extend with a custom decoder/rule that flags mismatched authority and host values, or normalize these fields at the log source before forwarding.

Mitigation & Patch Guidance

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

The NVD description states the issue is fixed in 4.2.18.Final, but no vendor advisory, changelog entry, commit hash, or CVE-to-version confirmation has been verified by any tracked source. Treat all version guidance as provisional and confirm against the official Netty release notes and/or a vendor advisory before relying on it.

1. Immediate mitigations (no patch required):

   • Enforce the RFC 9114 invariant at the edge. Configure any HTTP/3-capable reverse proxy, load balancer, API gateway, or service mesh ingress fronting the affected Netty service to reject requests where :authority and a literal host header are both present and differ. If the front end cannot inspect HTTP/3 headers, terminate HTTP/3 upstream of the vulnerable component and enforce the check on the decoded HTTP layer.
   • Normalize header consumption. Ensure every component in the request path (proxy, gateway, application, framework) derives the effective authority from a single, canonical source (e.g., :authority only, or host only after explicit normalization) so the dual-field divergence cannot drive disjoint decisions.
   • Restrict network reachability of the HTTP/3/QUIC endpoint to trusted clients where practical, reducing the remote unauthenticated attack surface.
   • Disable HTTP/3 on the affected codec until upgrade is possible, falling back to HTTP/1.1 or HTTP/2 listeners. This removes the vulnerable parsing path entirely.
   • Harden authorization so that virtual-host, tenant, and ACL decisions do not depend on a single attacker-influenced header; apply defense-in-depth authorization at the application layer keyed to authenticated identity rather than request authority.

2. Patch / upgrade steps:

   • If Netty is a direct dependency: update io.netty:netty-codec-http3 to the version that includes the fix, per the NVD statement 4.2.18.Final. Verify the resolved artifact version via your dependency manager (mvn dependency:tree, gradle dependencies) to confirm transitive upgrades.
   • Update any framework, server, or library that bundles Netty (application servers, gRPC stacks, proxies) so the patched Netty transitive dependency is pulled in; a direct upgrade of the top-level library may not change the bundled Netty version.
   • Because patch confidence is 0/4, independently verify that 4.2.18.Final (or the vendor-recommended version) actually resolves the issue by reference to the official release notes and the CVE record, and regression-test HTTP/3 request handling with both matching and mismatched authority/host fields before deployment.

3. Long-term hardening:

   • Normalize and reconcile all HTTP request metadata (authority, host, scheme, path) at the first point of trust, and reject ambiguous or conflicting fields by default.
   • Treat discrepancies between :authority and host as a security event and alert on them across all HTTP versions, not just HTTP/3.
   • Maintain an inventory of components that embed Netty and a process to track Netty CVEs and upgrade transitively bundled copies.
   • Adopt a "reject-on-ambiguity" posture for header parsing in edge components to defend against the broader class of HTTP desync and authority-confusion vulnerabilities.

References

• NVD — CVE-2026-100659: https://nvd.nist.gov/vuln/detail/CVE-2026-100659
• Netty project (official site / release notes for version 4.2.18.Final): https://netty.io/
• RFC 9114 — HTTP/3 (requirement that :authority and host match when both present): https://www.rfc-editor.org/rfc/rfc9114
• RFC 9000 — QUIC transport protocol: https://www.rfc-editor.org/rfc/rfc9000
• CWE-444 — Inconsistent Interpretation of HTTP Requests: https://cwe.mitre.org/data/definitions/444.html
• CISA Known Exploited Vulnerabilities Catalog (not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild status: No public proof-of-concept, exploit code, Nuclei template, or known threat-actor campaign associated with CVE-2026-100659 is present in the provided data. EPSS has not yet scored this CVE. It is not listed in CISA KEV.