CRLF Header Injection in Netty HttpProxyHandler Can Alter HTTP CONNECT Requests

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders without any CRLF validation. This allows an attacker who can influence the outbound headers to inject arbitrary HTTP headers into the CONNECT request sent to the proxy server. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

• io.netty:netty-handler-proxy in the 4.2 branch is affected for >= 4.2.0.Alpha1, < 4.2.13.Final; the advisory identifies 4.2.13.Final as the patched release.
• io.netty:netty-handler-proxy in the 4.1 branch is affected for < 4.1.133.Final; the advisory identifies 4.1.133.Final as the patched release.
• These are upstream boundaries. Downstream distributions can backport the fix, so each vendor product must be assessed using its own advisory or erratum rather than the upstream package string alone. Branches or products outside the stated boundaries are not classified here.

The flaw is in io.netty.handler.proxy.HttpProxyHandler, specifically newInitialMessage(). The implementation creates the CONNECT request with DefaultHttpHeadersFactory.headersFactory().withValidation(false) and then adds application-supplied outboundHeaders without CRLF validation. If an attacker can influence a header value, embedded CRLF sequences can terminate the original header line and add further HTTP headers to the serialized CONNECT request. The attack therefore crosses from application-controlled input into a proxy-facing request and does not require the attacker to control Netty internals. The authoritative evidence does not establish a universal entry point, the exact behavior of every proxy after injection, or impact beyond the affected CONNECT exchange.

Exploitation is remotely reachable when an application exposes a path that lets attacker-controlled data influence outboundHeaders; the supplied attack characteristics do not identify a separate Netty privilege requirement. No human interaction is identified, but the application must actually use HttpProxyHandler and send a CONNECT request through a proxy. The supplied record marks public exploit material as available, and the Netty advisory contains proof-of-concept material. The evidence reviewed does not document in-the-wild exploitation, a named campaign, or a specific victim.

• The direct technical outcome is arbitrary header injection into a proxy CONNECT request.
• An affected proxy may interpret injected headers as legitimate request metadata, changing authorization, routing, or other security decisions.
• Red Hat describes potential bypass of proxy security controls and cache-poisoning-style attacks, but these are deployment-dependent consequences, not guaranteed outcomes.
• The reviewed evidence does not establish code execution, direct data disclosure, or service unavailability from this issue alone.

Successful exploitation can alter the headers received by the proxy while it establishes a tunnel. Depending on proxy policy and the injected values, this could cause unexpected routing or authentication behavior, bypass proxy security controls, or enable cache-poisoning-style effects. The evidence establishes request and header manipulation, not a guaranteed compromise of the proxy or the application. Deployments that do not expose attacker influence over outbound proxy headers are not shown to be exploitable by this flaw.

1. Upgrade io.netty:netty-handler-proxy to 4.2.13.Final when using the 4.2 branch, or to 4.1.133.Final when using the 4.1 branch. Do not treat one branch’s fix as proof that another branch or downstream build is fixed.
2. If an upgrade is not immediately possible, ensure every user-controlled value placed in outboundHeaders is rigorously checked for CRLF before it reaches HttpProxyHandler. If maintaining a fork, restore header validation for this path or validate each outbound header before adding it.
3. Where comprehensive sanitization cannot be implemented, restrict network access to the application that uses HttpProxyHandler as a defense-in-depth measure.
4. Recheck shaded and transitive dependencies, then test proxy authentication and CONNECT behavior after the change. For vendor distributions, apply the vendor erratum and verify the effective shipped component because fixes may be backported.

1. Inventory direct, transitive, and shaded Maven dependencies for io.netty:netty-handler-proxy, and compare the effective component with the two affected branch boundaries.
2. Search application code and configuration for HttpProxyHandler, newInitialMessage(), outboundHeaders, and withValidation(false). Trace whether request, tenant, proxy, or user metadata can reach those values.
3. Review the application’s header validation or sanitization before the proxy request is serialized. Presence of the dependency alone does not prove that the vulnerable code path is reachable.
4. At the proxy boundary, review CONNECT requests for unexpected, duplicate, or newly introduced headers and for CRLF-related parsing anomalies. Treat this as precautionary monitoring, not as a confirmed indicator of exploitation.
5. After remediation, verify the resolved artifact or vendor erratum in the deployed image or runtime. Absence of suspicious proxy logs does not prove that the deployment is safe.