CVE-2026-50020: Netty HTTP Request Smuggling via Control Character Stripping

Technical summary

The vulnerability resides in HttpObjectDecoder's request-line parsing logic. Prior to the patched versions, the decoder invokes Character.isISOControl(b) to filter bytes 0x00–0x1F and 0x7F before reading the request-line, discarding them along with all whitespace characters. RFC 9112 §2.2 prescribes a narrower robustness allowance: servers should ignore only empty CRLF sequences (CR LF pairs with no intervening bytes) preceding the request-line, a provision designed for HTTP/1.0 POST workarounds. By consuming non-CRLF control characters, Netty deviates from this specification. When an HTTP request flows through multiple processing stages—particularly in pipelined HTTP/1.1 or multiplexed scenarios—a front-end component and the Netty back-end may disagree on request boundaries. An attacker can craft a request containing embedded control bytes; the front-end parses it as one request, but Netty strips the control bytes and parses it as a different request, creating an opportunity for request-smuggling or cache-poisoning attacks.

Business impact

This vulnerability enables request-smuggling attacks, which can lead to security-control bypass, cache poisoning, or unauthorized access to backend resources. In multi-tier architectures—common in modern cloud deployments—an attacker may craft a request that appears safe to a front-end web application firewall or load balancer but is reinterpreted by the Netty backend after control-byte stripping. The consequence ranges from credential theft (via request smuggling to steal authentication tokens) to website defacement or unauthorized data access. Organizations relying on Netty for HTTP service delivery, especially those positioned behind proxies or WAFs, face elevated risk of request-routing manipulation.

Affected systems

Netty versions prior to 4.1.135.Final and 4.2.15.Final are affected. Any application or service that (1) uses Netty as its HTTP server framework, (2) processes HTTP requests in pipelined or multiplexed transports, and (3) is positioned behind a front-end component (proxy, load balancer, WAF) that does not strip ISO control characters, is at risk. This includes microservice architectures, API gateways, and REST service backends built on Netty. Java applications in cloud or containerized environments are particularly relevant.

Exploitability

The CVSS 3.1 score of 5.3 (MEDIUM, network-accessible, no authentication required) reflects that exploitation requires network access and careful crafting of HTTP requests but does not require user interaction or elevated privileges. However, practical exploitation depends on the presence of a multi-tier architecture: the attack only works if a front-end component behaves differently from Netty with respect to control characters. In deployments where Netty is the sole HTTP entry point, the attack surface is reduced. In typical cloud architectures with proxies or load balancers, the conditions for exploitation are likely present. No public exploit code is known to be widely available, but the technique is conceptually straightforward for skilled attackers.

Remediation

Upgrade Netty to version 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. These releases modify HttpObjectDecoder to strictly adhere to RFC 9112, accepting only empty CRLF sequences before the request-line and rejecting other control characters. Verify against the official Netty release notes and your dependency management tool to confirm the upgrade path. Organizations unable to patch immediately should prioritize architectural review: if possible, ensure that front-end proxies are configured to reject or normalize requests containing control characters before they reach Netty, reducing the window for smuggling attacks.

Patch guidance

1. Identify all applications and services in your environment using Netty. Check your Maven pom.xml, Gradle build.gradle, or equivalent dependency files for netty-codec-http versions. 2. For 4.1.x users: upgrade to 4.1.135.Final or later. 3. For 4.2.x users: upgrade to 4.2.15.Final or later. 4. After upgrading, rebuild, test in a staging environment, and deploy to production. 5. Verify that the patched version is in use by checking classpath or running version-detection tooling. 6. Consider using dependency-management tools (e.g., Maven Enforcer, Gradle constraint) to prevent accidental downgrades.

Detection guidance

Monitor HTTP request logs for unusual byte sequences or control characters in request paths or headers. While legitimate HTTP should not contain 0x00–0x1F or 0x7F characters (except CR, LF, and TAB in specific contexts), attackers may embed them to exploit the control-character stripping. Implement WAF or proxy rules that detect and block requests containing non-standard control bytes. Additionally, compare request boundaries as seen by front-end components versus backend logs: discrepancies may indicate smuggling attempts. Intrusion-detection systems should flag HTTP requests containing NUL, SOH, STX, or other non-printable control bytes.

Why prioritize this

Although the CVSS score is MEDIUM, the vulnerability warrants prompt attention because (1) it is network-accessible with no authentication, (2) request-smuggling attacks can undermine multiple layers of security infrastructure, (3) Netty is widely deployed in microservice and cloud architectures where the multi-tier conditions for exploitation are common, and (4) the patch is straightforward to apply. Organizations should prioritize Netty upgrades in their patch schedule, especially for internet-facing services and those behind proxies or WAFs.

Risk score, explained

CVSS 3.1 assigns a score of 5.3 (MEDIUM) based on: Attack Vector = Network (exploitable remotely), Attack Complexity = Low (no special conditions beyond crafting malicious HTTP), Privileges Required = None, User Interaction = None, Scope = Unchanged (impact is limited to the Netty service, not system-wide), Confidentiality = None (no data disclosure), Integrity = Low (request smuggling can modify behavior or contents), and Availability = None (no denial-of-service component). The MEDIUM rating appropriately reflects the need for a multi-tier architecture and careful request crafting, but does not diminish the practical risk in common deployments.

Frequently asked questions