CVE-2026-42578

What it actually does

Netty's HttpProxyHandler builds HTTP CONNECT requests for an upstream proxy using outbound headers supplied by the application, but in affected versions it explicitly disables header validation with withValidation(false). If untrusted input can reach those outboundHeaders, carriage return/line feed characters can break out of the intended header value and inject additional HTTP headers into the CONNECT request sent to the proxy. The direct impact is request/header injection toward the proxy layer, which may alter proxy behavior, bypass proxy controls, poison proxy logs, or influence authentication/routing decisions depending on how the proxy and surrounding application use CONNECT headers. The flaw is fixed in Netty 4.2.13.Final and 4.1.133.Final.

Why it matters to the business

Applications that use Netty for proxied outbound connections may allow an external user to tamper with traffic sent through corporate or service proxies if the application passes user-controlled data into proxy CONNECT headers. This can undermine proxy-based access controls, auditing, and routing assumptions, and may create compliance or incident-response complications because proxy logs could reflect attacker-injected headers rather than the application's intended request. Netty is a widely embedded Java networking library, so exposure may exist indirectly through downstream frameworks and products even when teams do not use Netty directly. Current public exploitation signals are low: EPSS is approximately 0.0095 and stable over 30 days, it is not listed in CISA KEV, and no known exploit maturity is reported; however, affected internet-facing services should still be reviewed because exploitation requires only network access plus an application path that lets attackers influence outbound proxy headers.

How an attack unfolds

An attacker first identifies an application or service that uses Netty's HttpProxyHandler to create outbound HTTP CONNECT tunnels through a proxy. The attacker then finds an input that the application copies into outboundHeaders for the proxy request, such as a user-supplied header, destination metadata, tenant-controlled configuration value, callback/webhook option, or other field used when constructing proxy headers. The attacker submits a value containing CRLF sequences followed by a crafted header name and value. Because affected Netty versions disable header validation when building the CONNECT request, the CRLF sequence is not rejected or normalized, and the attacker-controlled bytes are serialized into the request sent to the proxy as additional headers. The proxy receives a CONNECT request that contains headers the application did not intend to send. Depending on proxy policy, this may let the attacker influence authentication-related headers, routing headers, audit fields, allowlist decisions, or downstream proxy behavior. Successful exploitation is application-dependent: Netty must be present in an affected version, HttpProxyHandler must be used, and attacker-controlled data must reach outboundHeaders.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later for the 4.2.x line, or 4.1.133.Final or later for the 4.1.x line. Because Netty is often pulled in transitively, inspect dependency trees for all Java services, frameworks, application servers, SDKs, and vendor components that embed io.netty artifacts. If an immediate upgrade is not possible, reduce exposure by ensuring untrusted input is never copied into HttpProxyHandler outboundHeaders, reject or encode CR and LF characters in any value that may become an outbound proxy header, allowlist permitted proxy header names and values, and avoid forwarding user-controlled headers to proxy CONNECT requests. Where feasible, configure proxies to reject malformed CONNECT requests, duplicate sensitive headers, unexpected proxy authentication headers, or headers containing control characters. Rebuild and redeploy affected applications after dependency updates; updating a shared library repository alone is not sufficient if packaged applications still contain older Netty jars.

How to confirm the fix worked

Confirm remediation by checking dependency manifests and built artifacts for Netty versions. For Maven, review `mvn dependency:tree` output for `io.netty`; for Gradle, review `gradle dependencies` or dependency locking files; for packaged Java artifacts, inspect bundled jars for names such as `netty-handler-proxy-4.1.x.Final.jar`, `netty-codec-http-4.1.x.Final.jar`, and related `io.netty` modules. Validate that all deployed components use Netty 4.2.13.Final or later, or 4.1.133.Final or later. Perform a focused negative test in a non-production environment by attempting to pass a header value containing CRLF into any application-controlled outbound proxy header path and confirming the application or library rejects it rather than sending injected headers to the proxy. Review proxy access logs or packet captures during testing to verify CONNECT requests contain only intended headers and no attacker-supplied additional header lines.

Typical attack path

1. Identify a service or product that uses an affected Netty version before 4.2.13.Final or 4.1.133.Final.
2. Determine whether the service uses Netty HttpProxyHandler for outbound HTTP CONNECT connections through a proxy.
3. Find an input path that is copied into outbound proxy headers, such as user-provided HTTP headers, webhook settings, callback metadata, or proxy configuration fields.
4. Submit a crafted value containing CRLF characters followed by an injected HTTP header.
5. Trigger the application to initiate the proxied outbound connection.
6. The affected Netty code serializes the CONNECT request without validating the attacker-controlled header value.
7. The proxy receives additional attacker-injected headers and may apply altered routing, authentication, logging, or policy behavior.

How to detect it

Detection should focus on applications that initiate outbound HTTP CONNECT requests through proxies and accept user-controlled data that could influence proxy headers. Review forward proxy logs, proxy authentication logs, application request logs, WAF logs, and packet captures for CONNECT requests containing unexpected headers, duplicate sensitive headers, encoded or decoded CRLF sequences, or header names that normally should never be supplied by the application. Look for inbound requests containing `%0d%0a`, `%0D%0A`, raw carriage return/line feed characters, or unusual header-like payloads shortly before the same application makes an outbound CONNECT request. Compare normal CONNECT header baselines against observed traffic; suspicious additions may include unexpected `Proxy-Authorization`, `X-Forwarded-For`, `Forwarded`, `Host`, routing, tenant, or policy-related headers. Because no public actor-specific exploitation is reported and injected header names are attacker-chosen, absence of a single fixed IOC does not rule out exploitation. Correlate suspicious proxy CONNECT activity with application features that create outbound connections such as webhooks, callbacks, URL fetchers, integrations, or tunneling functionality.

• %0d%0a
• %0D%0A
• \r\nProxy-Authorization:
• \r\nX-Forwarded-For:
• \r\nForwarded:
• \r\nHost:
• CONNECT .*%0d%0a
• CONNECT .*%0D%0A
• CONNECT .*\\r\\n
• netty-handler-proxy-4.1.
• netty-handler-proxy-4.2.
• DefaultHttpHeadersFactory.headersFactory().withValidation(false)

What your security team should do

• Inventory Java applications and vendor products for embedded `io.netty` dependencies, including transitive dependencies and shaded jars.
• Prioritize internet-facing services, webhook/callback processors, API gateways, SSRF-prone components, and systems that make outbound connections through HTTP proxies.
• Upgrade affected Netty dependency lines to 4.2.13.Final or later, or 4.1.133.Final or later, then rebuild and redeploy applications.
• Add input validation or output encoding to block CR, LF, and other HTTP control characters in values that can become outbound proxy headers.
• Review code paths using `HttpProxyHandler` and ensure `outboundHeaders` are not populated from untrusted request data without strict allowlisting.
• Harden proxy policy to reject malformed CONNECT requests, unexpected sensitive headers, duplicate authentication/routing headers, and control characters in header values.
• Search proxy and application logs for historical evidence of CRLF/header injection attempts, especially around features that initiate outbound proxied connections.
• Track downstream framework and vendor advisories because Netty is commonly embedded and fixed versions may arrive through framework-specific releases.