Netty CVE-2026-93573

Exploitation requires that the Netty HTTP decoder is deployed in an HTTP chain alongside a second HTTP parser (a reverse proxy, load balancer, CDN, WAF, or upstream/downstream server) that interprets split or duplicated Transfer-Encoding header fields differently from Netty - this parser disagreement is the load-bearing precondition without which no smuggling occurs. The attacker must reach an HTTP listener that routes requests through such a component and be able to send a raw crafted request preserving the malformed Transfer-Encoding fields (some intermediaries normalize headers and neutralize the attack). No authentication is required per PR:N and no user interaction per UI:N, but the practical limiter is the proxy/backend topology: a standalone Netty service with no differing front-end is not realistically exploitable for cross-request impact. Affected only in the unpatched Netty versions bundled in the listed Red Hat products.

This is a real but moderate-priority vulnerability whose severity depends almost entirely on deployment topology rather than the raw 6.5 CVSS score. The vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) suggests trivially remote and unauthenticated, but that overstates real-world ease: HTTP request smuggling per CWE-444 only becomes exploitable when Netty sits behind or in front of another HTTP parser (reverse proxy, load balancer, WAF, or backend) that disagrees on how split/duplicated Transfer-Encoding fields terminate a chunked body. Against a standalone Netty endpoint the vendor's own C:L/I:L is arguably generous - the vector's low-complexity assumption ignores the fronting-proxy desync prerequisite, which realistically pushes attack complexity toward AC:H and can produce a scope change (S:C) when a smuggled request is served to another user or bypasses front-end authorization. No EPSS score, no CISA KEV listing, and no public POC were provided (no SSVC data either), so there is no signal of active or automated exploitation; this is a defense-in-depth desync flaw, not a mass-exploitation event. The 'Authentication Bypass' tag conflicts with the CWE-444 request-smuggling classification and the vendor's C:L/I:L (not an auth-bypass impact profile) - verify the tag against the Red Hat advisory. Treat as a patch-in-normal-cycle item unless Netty is deployed behind a differing proxy handling untrusted traffic.

An attacker sends a single crafted HTTP request in which the Transfer-Encoding header is split or duplicated across fields so a front-end proxy and the Netty-based backend disagree on where the chunked body ends. The unvalidated trailing bytes are interpreted by Netty as the start of a second, smuggled request, letting the attacker prepend content to another user's connection, poison caches, or bypass front-end access controls. No public exploit code was identified in the provided data, and exploitation requires a proxy/backend pair that parses Transfer-Encoding differently.