Netty CVE-2026-93566

Exploitation requires that Netty's HTTP decoder (HttpObjectDecoder / HttpRequestDecoder) parse attacker-supplied requests, and - critically - that Netty be deployed behind or in front of another HTTP intermediary (reverse proxy, load balancer, or CDN) that disagrees on chunk-line framing, so the bare-CR chunk-size line ('0\rX', no ';' chunk extension) causes a request-boundary desync. No authentication or user interaction is needed to send the crafted request, but a standalone Netty service with no differing intermediary in the chain yields little practical smuggling impact, which limits real-world exploitability to multi-hop HTTP architectures.

This is a genuine but moderate-priority integrity flaw. The vendor CVSS3.1 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) marks it network-reachable and unauthenticated, which is accurate - Netty's HttpObjectDecoder is a passive parser reachable by any client. However, the practical risk depends entirely on deployment topology: HTTP request smuggling only produces impact when Netty sits behind or in front of another HTTP intermediary (proxy/load balancer/CDN) that parses chunk framing differently, creating a front-end/back-end desync. That precondition is not captured by AC:L and realistically pushes real-world exploitation toward AC:H. No EPSS score, no CISA KEV entry, and no exploitation reporting are present in the input, so there is no signal of active exploitation. A working PoC (a JUnit test using HttpRequestDecoder) is embedded directly in the advisory description, so exploit code is public. The CWE-1035 assignment is a VulnDB category, not a weakness - the real classification is CWE-444 (HTTP request smuggling), and the 'Information Disclosure' tag understates/mislabels it (smuggling primarily bypasses access controls and enables request routing manipulation). Net: treat as a real defense-in-depth fix for internet-facing Java services, not an emergency, absent any exploitation evidence.

An attacker sends a POST with 'Transfer-Encoding: chunked' whose terminating chunk-size line contains a bare CR without a chunk extension (e.g. '0\rX'), which Netty accepts instead of rejecting. When Netty is paired with a front-end proxy that interprets the framing differently, the trailing bytes are treated as a second smuggled request ('GET /smuggled'), letting the attacker poison the connection, bypass front-end access controls, or hijack another user's request. A public PoC JUnit test demonstrating the parser acceptance is included in the advisory.