CVE-2026-42581: Netty HTTP request smuggling in HttpObjectDecoder

CVE-2026-42581 · Severity: medium · CVSS 5.8 · Published 2026-05-13

Netty is a widely used networking framework that helps applications communicate over the internet. A flaw in how it handles certain web requests allows an attacker to 'smuggle' hidden commands past security filters by confusing the system about where one request ends and the next begins. This could allow an attacker to bypass security controls, access restricted internal data, or interfere with other users' web sessions.

Technologies: io.netty:netty-codec-http (Maven), Netty Project Netty codec-http. Vendors: Maven, Netty Project.

Quick answers

Is CVE-2026-42581 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-42581 being exploited in the wild.
How severe is CVE-2026-42581?
Medium severity, with a CVSS score of 5.8, published 13 May 2026.
Which products and versions are affected?
io.netty:netty-codec-http (Maven) ECOSYSTEM:introduced=4.2.0.Alpha1,fixed=4.2.13.Final.
Is there a fix for CVE-2026-42581?
Yes. io.netty:netty-codec-http (Maven): upgrade to 4.2.13.Final or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-42581 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-42581?
Check whether you run io.netty:netty-codec-http (Maven) or Netty Project Netty codec-http at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • io.netty:netty-codec-http (Maven): upgrade to 4.2.13.Final or later
    # set io.netty:netty-codec-http to 4.2.13.Final in your pom.xml or build.gradle

Technical details

A request smuggling vulnerability exists in Netty's HttpObjectDecoder due to inconsistent handling of HTTP/1.0 vs HTTP/1.1 protocol versions. While Netty correctly strips the Content-Length header when Transfer-Encoding: chunked is present in HTTP/1.1, it fails to do so for HTTP/1.0 requests. An attacker can send a specially crafted HTTP/1.0 request with both headers, causing Netty to process the body as chunked while forwarding the original Content-Length to downstream components. If a downstream proxy prioritizes Content-Length, it will misinterpret the message boundaries, allowing the attacker to inject a second, 'smuggled' request. This is fixed in versions 4.2.13.Final and 4.1.133.Final.

Affected products

  • Netty netty-codec-http <= 4.2.12.Final, <= 4.1.132.Final

Identifiers

  • CVE-2026-42581
  • GHSA-xxqh-mfjm-7mv9

Timeline

  • 2026-05-05: advisory: GitHub advisory GHSA-xxqh-mfjm-7mv9 published
  • 2026-05-13: disclosed: CVE-2026-42581 published to NVD

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.