Netty EUVD-2026-87758

Requires the vulnerable component to be deployed as a Netty-based HTTP/1-to-HTTP/3 gateway, proxy, or protocol bridge that invokes Http3FrameToHttpObjectCodec(false), which routes through HttpConversionUtil.toHttp3Headers. Exploitation depends on the deployment performing security decisions (allow-list checks, virtual-host routing, backend selection, cache keying, or URL generation) based on the absolute-form request-target authority while the codec derives :authority from the Host header. The attacker must be able to send absolute-form HTTP/1.1 requests (e.g., 'GET https://trusted.example/admin HTTP/1.1') with a conflicting Host header. No authentication or user interaction is required (PR:N/UI:N). The primary limiting factor is that plain Netty deployments not acting as HTTP/1↔HTTP/3 bridges never reach this code path, so the flaw is unreachable outside gateway/proxy topologies. Affected versions 4.2.2.Final through 4.2.17.Final; fixed in 4.2.18.Final.

This is a genuine but bounded (not top-tier) issue. The vendor CVSS 4.0 is 8.7 (AV:N/AC:L/PR:N/UI:N with VI:H and all other impacts N), reflecting an unauthenticated, low-complexity network vector with integrity-only impact - the advisory explicitly states no code execution, memory corruption, or availability impact, so this is NOT the RCE/buffer-overflow the tags imply. No EPSS score, KEV entry, or public POC is provided in the input, so the real-world exploitation signal is: no public exploit identified at time of analysis. The score is high because the base metrics are attacker-friendly, but the practical risk is gated by a specific deployment topology: the flaw only manifests in a Netty-based HTTP/1-to-HTTP/3 gateway/proxy/bridge using Http3FrameToHttpObjectCodec(false). Where that topology exists, the impact (allow-list/authorization bypass, virtual-host routing confusion, backend selection, cache-key poisoning) is real and security-relevant; where it does not, the code path is unreachable. Net: a real priority for the subset of Netty deployments acting as HTTP/1↔HTTP/3 protocol bridges, but a high-CVSS-with-limited-blast-radius issue for the broad Netty install base, and a request-target-vs-Host confusion - not the memory-corruption class its tags suggest.

A remote unauthenticated client sends an absolute-form request such as 'GET https://trusted.example/admin HTTP/1.1' with a conflicting 'Host: attacker.example' header to a Netty HTTP/1-to-HTTP/3 gateway. The front-end validates or authorizes on the RFC-defined request-target authority (trusted.example) while the codec builds the HTTP/3 :authority from the Host header (attacker.example), so the upstream HTTP/3 peer sees a different authority than the security check - bypassing allow-lists or mis-routing vhosts. No public POC is identified in the input; exploitation requires no authentication and low complexity per the CVSS vector.