High priorityDisclosed

Advisory · CVE-2026-100663

Netty mistranslates CONNECT request-targets, letting proxies tunnel the wrong authority

Netty's HTTP/3 codec mishandles HTTP/1 CONNECT authority-form request-targets when converting to HTTP/3: the CONNECT target's host is emitted as the scheme, the path becomes /, and the HTTP/1 Host header becomes the authority, or the target is dropped entirely. In an HTTP/1-to-HTTP/3 proxy, a client can bypass tunnel allow-lists and egress policy with a CONNECT whose Host header names a different authority than the request-target. Fixed in 4.2.18.Final.

Advisory published September 26, 2026Independent summary
Vendor
Netty
Product
Netty
Identifier / CWE
CVE-2026-100663
CWE-20
Action timing
Immediate
ELI5

Explain it like I’m five

A translator misreads a travel order: instead of forwarding the destination as written, it copies the address from a different line of the form. A traveler uses the mix-up to get the gate to open a tunnel to the wrong place.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Crafted CONNECT

    The client sends an HTTP/1 CONNECT with an authority-form request-target and a Host header naming a different authority.

  2. 02Mistranslation

    Netty emits the CONNECT target's host as the scheme, the path as /, and the Host header as the authority, or drops the target.

  3. 03Allow-list split

    Proxy policy sees one authority while the upstream HTTP/3 peer receives another.

  4. 04Tunnel bypass

    The client tunnels to a destination the proxy policy would have blocked.

What happened

Netty’s HTTP/3 codec mishandles HTTP/1 CONNECT authority-form request-targets when converting them to HTTP/3 (CVE-2026-100663, CVSS 8.7). The CONNECT target’s host is emitted as the scheme, the path becomes /, and the HTTP/1 Host header becomes the authority, or the target is dropped entirely. In an HTTP/1-to-HTTP/3 proxy, this lets a client bypass tunnel allow-lists and egress policy: policy enforcement sees one authority while the upstream HTTP/3 peer receives another. The issue is fixed in Netty 4.2.18.Final.

What to do

  1. Upgrade Netty to 4.2.18.Final on any HTTP/1-to-HTTP/3 proxy or gateway.
  2. Review proxy tunnel allow-lists and egress logs for CONNECT traffic that resolved to unexpected authorities.
  3. Where possible, validate CONNECT request-targets against the Host header before proxying.

Management note

Protocol translation layers are classic policy-bypass territory: every translation is a chance for two components to disagree about what a request says. If you proxy between HTTP versions on Netty, patch and audit.