CVE-2026-50020

What it actually does

Netty's HTTP/1 decoder accepted and silently skipped leading ISO control characters and whitespace before the first HTTP request line. HTTP servers are only expected to tolerate empty CRLF lines before a request line, so accepting bytes such as NUL, SOH, STX, and other non-CRLF control characters can cause one HTTP component to interpret request boundaries differently than another. In architectures using reverse proxies, gateways, load balancers, HTTP pipelines, connection reuse, or protocol translation in front of Netty-based services, this can enable request-boundary confusion and limited HTTP request smuggling-style behavior. The assessed impact is primarily integrity-related: an attacker may influence how requests are parsed or routed, but the issue does not inherently provide code execution, authentication bypass, or direct data disclosure by itself.

Why it matters to the business

Applications and services built on vulnerable Netty versions may process malformed HTTP traffic differently than upstream infrastructure, creating a risk that attackers can interfere with request handling, bypass some front-end assumptions, poison request streams, or trigger unexpected backend behavior. The severity is moderate because exploitation requires a parser discrepancy in the deployment path, but exposure can be broad where Netty is embedded in application servers, API gateways, service frameworks, or downstream Java components. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but internet-facing services using affected Netty versions should still be prioritized because the attack is network-reachable and unauthenticated.

How an attack unfolds

An attacker targets a service path where an upstream HTTP component, such as a proxy or load balancer, forwards traffic to a Netty-based backend. The attacker sends a crafted HTTP/1 request or pipelined sequence containing non-CRLF control characters before what Netty will treat as the first request line. If the front-end component rejects, preserves, logs, normalizes, or frames those bytes differently than Netty, the two components can disagree about where one request ends and the next begins. The attacker then uses that disagreement to influence how the backend interprets subsequent bytes on the connection, potentially causing a request to be handled under the wrong boundary, route, or security context. Practical exploitation depends on the exact proxy/backend pairing, connection reuse behavior, HTTP keep-alive or pipelining support, and whether intermediaries normalize or block control characters before forwarding.

How to fix it

Upgrade Netty to a patched release: 4.1.135.Final or later for the 4.1.x line, or 4.2.15.Final or later for the 4.2.x line. Because Netty is frequently embedded transitively in Java frameworks and application servers, review direct and transitive dependencies, shaded JARs, container images, and vendor-packaged components. If immediate upgrade is not possible, mitigate by configuring upstream proxies, WAFs, API gateways, and load balancers to reject HTTP requests containing non-CRLF control characters before the request line; disabling HTTP/1.1 pipelining where feasible; avoiding backend connection reuse across trust boundaries where feasible; and ensuring malformed HTTP requests are consistently rejected before reaching Netty-based services. Prefer canonical dependency management updates over ad hoc binary replacement, and redeploy/restart affected services after updating libraries.

How to confirm the fix worked

Confirm that deployed applications no longer include Netty versions earlier than 4.1.135.Final on the 4.1.x branch or earlier than 4.2.15.Final on the 4.2.x branch. Use software composition analysis, build manifests, dependency lock files, SBOMs, JAR inspection, and runtime classpath checks to identify both direct and transitive Netty usage. Functionally validate the fix by sending controlled test requests with leading non-CRLF control bytes before the HTTP method and confirming they are rejected consistently rather than silently skipped. Test through the full production-like request path, including proxies and load balancers, because the risk depends on front-end/back-end parser disagreement. Verify that WAF or gateway rules log and block such requests and that no backend application receives them.

Typical attack path

1. Identify an internet-facing or internal HTTP service that uses a vulnerable Netty version before 4.1.135.Final or 4.2.15.Final.
2. Determine whether the service is behind a front-end proxy, load balancer, gateway, CDN, or other HTTP intermediary with different request parsing behavior.
3. Send probe requests containing leading non-CRLF control characters, such as NUL or SOH bytes, before the HTTP request line.
4. Compare front-end and backend behavior for status codes, timing, connection reuse, header handling, and request ordering anomalies.
5. If parser disagreement is observed, craft pipelined or connection-reuse payloads that cause Netty to skip bytes the front-end treats differently.
6. Use the resulting request-boundary confusion to influence backend request interpretation, potentially affecting routing, authorization assumptions, cache behavior, or request sequencing.

How to detect it

Look for evidence of malformed HTTP/1 traffic containing non-CRLF control characters before the request line, especially immediately before common methods such as GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD, or CONNECT. Useful sources include raw packet captures, full-fidelity reverse proxy logs, WAF logs, load balancer logs, HTTP gateway logs, CDN security events, application access logs that preserve escaped bytes, and backend error logs. Standard access logs may not retain NUL or other binary control bytes, so packet capture, WAF raw-request logging, or proxy debug logs may be required. Investigate sequences where an intermediary reports a malformed request, 400 response, request truncation, connection reset, or unusual keep-alive behavior while the backend logs a different request on the same connection. Also look for request smuggling symptoms such as mismatched request counts between proxy and backend, unexpected backend-only requests, anomalous 4xx/5xx bursts, duplicate or out-of-order requests on reused connections, unexplained cache or routing anomalies, and payloads that contain escaped control-byte notation before an HTTP method. There are no public named threat actors or campaigns associated with this issue in the provided intelligence, and exploitation is not known to be mature, so detection should focus on malformed-request probing and parser-desynchronization artifacts rather than actor-specific tooling.

• \x00GET
• \x00POST
• \x00PUT
• \x00DELETE
• \x00PATCH
• \x00OPTIONS
• \x00HEAD
• \x00CONNECT
• \x01GET
• \x01POST
• \x02GET
• \x02POST
• \x03GET
• \x04GET
• \x05GET
• \x06GET
• \x07GET
• \x08GET
• \x0bGET
• \x0cGET
• \x0eGET
• \x0fGET
• \x10GET
• \x11GET
• \x12GET
• \x13GET
• \x14GET
• \x15GET
• \x16GET
• \x17GET
• \x18GET
• \x19GET
• \x1aGET
• \x1bGET
• \x1cGET
• \x1dGET
• \x1eGET
• \x1fGET
• \x7fGET
• %00GET
• %00POST
• %01GET
• %02GET
• %7fGET
• NULGET
• NUL POST
• malformed request
• invalid request line
• bad request line
• io.netty.handler.codec.http.HttpObjectDecoder

What your security team should do

• Inventory all Java services, frameworks, gateways, and vendor appliances that bundle or depend on Netty, including transitive and shaded dependencies.
• Upgrade affected Netty deployments to 4.1.135.Final or later, or 4.2.15.Final or later, prioritizing internet-facing services and systems behind HTTP intermediaries.
• Add or verify edge controls that reject requests with leading control characters other than permitted CRLF line endings before the HTTP request line.
• Review reverse proxy, load balancer, and gateway configurations for HTTP/1.1 keep-alive, pipelining, connection pooling, and malformed request handling behavior.
• Search historical proxy, WAF, packet capture, and application logs for malformed request probes containing leading NUL or other control bytes before HTTP methods.
• Create regression tests for HTTP parser consistency across the complete request path, not only the backend application.
• Monitor Netty advisories and downstream framework releases because many applications receive the fix through framework or platform upgrades rather than direct Netty dependency changes.