https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 13:54:47 +0000 https://vulnerability.circl.lu/vuln/ghsa-f6hv-jmp6-3vwv <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http, Maven: io.netty:netty-codec-http2</p> <p>## Summary</p> <p>`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.</p> <p>The same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections.</p> <p>## Details</p> <p>`HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler.</p> <p>For gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`:</p> <p>```java // HttpContentDecompressor.java:101 — maxAllocation IS enforced .handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation)) ```</p> <p>`ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer&#39;s `maxCapacity` and throwing `DecompressionException` when the limit is reached:</p> <p>```java // 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 DecompressionExcepti…</p> <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http, Maven: io.netty:netty-codec-http2</p> <p>## Summary</p> <p>`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.</p> <p>The same vulnerability exists in `DelegatingDecompressorFrameListener` for HTTP/2 connections.</p> <p>## Details</p> <p>`HttpContentDecompressor` stores the `maxAllocation` value at construction time (`HttpContentDecompressor.java:89`) and uses it in `newContentDecoder()` to create the appropriate decompression handler.</p> <p>For gzip/deflate, `maxAllocation` is forwarded to `ZlibCodecFactory.newZlibDecoder()`:</p> <p>```java // HttpContentDecompressor.java:101 — maxAllocation IS enforced .handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation)) ```</p> <p>`ZlibDecoder.prepareDecompressBuffer()` enforces this as a hard cap by setting the buffer&#39;s `maxCapacity` and throwing `DecompressionException` when the limit is reached:</p> <p>```java // 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 DecompressionExcepti…</p> https://vulnerability.circl.lu/vuln/ghsa-f6hv-jmp6-3vwv