CVE-2026-42578

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.

Security Vulnerability Report: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty

1. Vulnerability Summary

| Field | Value | |-------|-------| | Product | Netty | | Version | 4.2.12.Final (and all prior versions) | | Component | io.netty.handler.proxy.HttpProxyHandler | | Vulnerability Type | CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers | | Impact | HTTP Header Injection in CONNECT Proxy Requests | | CVSS 3.1 Score | 7.5 (High) | | CVSS 3.1 Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N | | Related Advisory | GHSA-84h7-rjj3-6jx4 (Incomplete Fix) |

2. Affected Components

• io.netty.handler.proxy.HttpProxyHandler — newInitialMessage() method (line 176) explicitly disables header validation via withValidation(false)

3. Vulnerability Description

Netty's HttpProxyHandler constructs HTTP CONNECT requests with header validation explicitly disabled. The newInitialMessage() method (line 176) creates headers using DefaultHttpHeadersFactory.headersFactory().withValidation(false), then adds user-provided outboundHeaders (line 188-190) 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.

Root Cause

// HttpProxyHandler.java:176-190
protected Object newInitialMessage(ChannelHandlerContext ctx) throws Exception {
    // ...
    HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
        .withValidation(false);  // <-- VALIDATION EXPLICITLY DISABLED

    FullHttpRequest req = new DefaultFullHttpRequest(
        HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
        url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);

    req.headers().set(HttpHeaderNames.HOST, hostHeader);

    if (authorization != null) {
        req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION, authorization);
    }

    if (outboundHeaders != null) {
        req.headers().add(outboundHeaders);  // <-- USER HEADERS ADDED WITHOUT VALIDATION
    }

    return req;
}

The outboundHeaders parameter comes from the HttpProxyHandler constructor (lines 80-93, 99-127), which is supplied by application code.

Incomplete Fix of GHSA-84h7-rjj3-6jx4

This vulnerability represents an incomplete fix of the previously acknowledged security advisory GHSA-84h7-rjj3-6jx4.

The GHSA-84h7-rjj3-6jx4 fix addressed HTTP CRLF injection by adding URI validation via validateRequestLineTokens() in DefaultHttpRequest and enabling header validation by default through DefaultHttpHeadersFactory. However, HttpProxyHandler explicitly opts out of the fix by calling withValidation(false), creating a gap where:

1. The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed
2. User-provided outboundHeaders are added without any CRLF check
3. The resulting CONNECT request contains unvalidated headers on the wire

This is not a new vulnerability class — it is the same CRLF injection that GHSA-84h7-rjj3-6jx4 was supposed to fix, but HttpProxyHandler was missed during the remediation. The fix for GHSA-84h7-rjj3-6jx4 should be extended to cover this code path.

4. Exploitability Prerequisites

This vulnerability is exploitable when:

1. An application uses HttpProxyHandler with user-influenced outboundHeaders
2. The application does not perform its own CRLF sanitization on header values

Common affected patterns:

• HTTP proxy clients that forward user-specified custom headers
• Web scraping frameworks that allow users to set proxy headers
• API gateways that pass user headers through a proxy tunnel

5. Attack Scenarios

Scenario 1: Proxy Authentication Bypass

HttpHeaders headers = new DefaultHttpHeaders(false);
headers.set("X-Forwarded-For", userInput);  // userInput from…

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-handler-proxy 4.1.100.Final-rhlw-00001 with a backported security fix.

CVE-2026-42578: Netty: HTTP Header Injection via HttpProxyHandler Disabled Validation

This patched artifact is a drop-in replacement for io.netty:netty-handler-proxy 4.1.100.Final from Maven Central.

Root has patched CVE-2026-42578 in the io.netty:netty-handler-proxy package for Root:Maven. Multiple fixed versions available.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

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.

TuxCare rebuilt 7 io.netty packages to address 10 CVEs. Fixed in 4.1.130.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 41 CVEs. Fixed in 4.1.112.Final-tuxcare.6.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

TuxCare rebuilt 12 io.netty packages to address 19 CVEs. Fixed in 4.1.75.Final-tuxcare.5.

TuxCare rebuilt 8 io.netty packages to address 9 CVEs. Fixed in 4.1.115.Final-tuxcare.9.

TuxCare rebuilt 14 io.netty packages to address 26 CVEs. Fixed in 4.1.118.Final-tuxcare.1.

TuxCare rebuilt 13 io.netty packages to address 24 CVEs. Fixed in 4.1.74.Final-tuxcare.1.

TuxCare rebuilt 9 io.netty packages to address 13 CVEs. Fixed in 4.1.113.Final-tuxcare.2.

TuxCare rebuilt 7 io.netty packages to address 12 CVEs. Fixed in 4.2.2.Final-tuxcare.2.

TuxCare rebuilt 5 io.netty packages to address 6 CVEs. Fixed in 4.1.72.Final-tuxcare.2.

TuxCare rebuilt 4 io.netty packages to address 8 CVEs. Fixed in 4.1.68.Final-tuxcare.2.

TuxCare rebuilt 14 io.netty packages to address 32 CVEs. Fixed in 4.1.64.Final-tuxcare.1.

TuxCare rebuilt 8 io.netty packages to address 8 CVEs. Fixed in 4.1.100.Final-tuxcare.3.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.114.Final-tuxcare.3.

TuxCare rebuilt 7 io.netty packages to address 6 CVEs. Fixed in 4.1.101.Final-tuxcare.3.

TuxCare rebuilt 3 io.netty packages to address 4 CVEs. Fixed in 4.1.99.Final-tuxcare.4.

TuxCare rebuilt 5 io.netty packages to address 7 CVEs. Fixed in 4.1.96.Final-tuxcare.3.

These are all security issues fixed in the netty-4.1.133-1.1 package on the GA media of openSUSE Tumbleweed.

This update for netty, netty-tcnative fixes the following issues

• CVE-2026-41417: missing validations leads to HTTP request smuggling and RTSP request injection via start-line injection in DefaultHttpRequest.setUri() (bsc#1264350).
• CVE-2026-42578: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty (bsc#1265243).
• CVE-2026-42579: DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding (bsc#1265272).
• CVE-2026-42580: chunk size parser silently overflows int and enables request smuggling attacks (bsc#1265273).
• CVE-2026-42581: TE+CL header coexistence in HTTP/1.0 requests bypasses smuggling sanitization (bsc#1265277).
• CVE-2026-42583: resource exhaustion and possible denial of service via Lz4FrameDecoder (bsc#1265279).
• CVE-2026-42584: improper handling of inbound responses in HttpClientCodec can lead to response desynchronization (bsc#1265280).
• CVE-2026-42585: Netty is an asynchronous, event-driven network application framework (bsc#1265292).
• CVE-2026-42586: CRLF Injection in Netty Redis Codec Encoder (bsc#1265245).
• CVE-2026-42587: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS (bsc#1265246).
• CVE-2026-44248: Netty is an asynchronous, event-driven network application framework (bsc#1265294).
• CVE-2026-42582: HTTP/3 QPACK literal unbounded allocation (bsc#1265318).

Changes for netty:

• Upgrade to upstream version 4.1.133

It was discovered that Netty's HTTP proxy handler did not properly validate headers when constructing CONNECT requests. An attacker could possibly use this issue to inject arbitrary HTTP headers into CONNECT requests. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42578)

It was discovered that Netty's DNS codec did not properly enforce domain name constraints. An attacker could possibly use this issue to bypass domain name validation, or cause Netty to consume resources, leading to a denial of service. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42579)

It was discovered that Netty did not correctly handle HTTP/1.0 requests containing both a Transfer-Encoding and Content-Length header. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42581)

Violeta Georgieva discovered that Netty incorrectly paired responses with requests when handling informational HTTP responses. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42584)

Violeta Georgieva discovered that Netty incorrectly parsed malformed Transfer-Encoding headers. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42585)

It was discovered that Netty's Redis encoder did not validate CRLF characters. An attacker could possibly use this issue to inject arbitrary Redis commands. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42586)