<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Netty-Codec-Http2 (&lt;= 4.1.132.Final) — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/netty-codec-http2--4.1.132.final/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 07 May 2026 00:46:35 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/netty-codec-http2--4.1.132.final/feed.xml" rel="self" type="application/rss+xml"/><item><title>Netty HttpContentDecompressor Brotli/Zstd/Snappy Decompression Bomb Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2026-05-netty-decompression-bomb/</link><pubDate>Thu, 07 May 2026 00:46:35 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-netty-decompression-bomb/</guid><description>Netty's HttpContentDecompressor and DelegatingDecompressorFrameListener are vulnerable to a decompression bomb denial-of-service attack because the maxAllocation parameter is not enforced when Content-Encoding is set to br (Brotli), zstd, or snappy, allowing attackers to bypass decompression limits and cause unbounded memory allocation.</description><content:encoded><![CDATA[<p>The Netty framework is susceptible to a decompression bomb vulnerability in its <code>HttpContentDecompressor</code> and <code>DelegatingDecompressorFrameListener</code> components. This flaw, present in versions up to 4.2.12.Final and 4.1.132.Final, arises because the <code>maxAllocation</code> parameter, intended to limit decompression buffer size, is ignored when content is encoded using Brotli (<code>br</code>), Zstandard (<code>zstd</code>), or Snappy. An attacker can exploit this by sending a specially crafted compressed payload with a <code>Content-Encoding</code> header set to one of the affected algorithms. This circumvents the configured memory limits, leading to excessive memory allocation and ultimately causing an out-of-memory denial-of-service (DoS) condition on the server. The vulnerability affects both HTTP/1.1 and HTTP/2 connections.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>The attacker identifies a Netty-based HTTP server that uses <code>HttpContentDecompressor</code> or <code>DelegatingDecompressorFrameListener</code> with a configured <code>maxAllocation</code> value.</li>
<li>The attacker crafts a malicious compressed payload designed to expand dramatically upon decompression (a &ldquo;decompression bomb&rdquo;). For example, a small compressed file expands to gigabytes of zeros.</li>
<li>The attacker sets the <code>Content-Encoding</code> HTTP header to <code>br</code>, <code>zstd</code>, or <code>snappy</code>.</li>
<li>The attacker sends an HTTP POST request to the vulnerable server, including the malicious compressed payload in the request body.</li>
<li>The server receives the request and <code>HttpContentDecompressor</code> or <code>DelegatingDecompressorFrameListener</code> processes the request, detects the <code>Content-Encoding</code>, and attempts to decompress it using the corresponding decoder (<code>BrotliDecoder</code>, <code>ZstdDecoder</code>, or <code>SnappyFrameDecoder</code>).</li>
<li>Because the <code>maxAllocation</code> is not enforced for these decoders, decompression proceeds without memory limits.</li>
<li>The decoder allocates memory to store the decompressed data, which rapidly consumes available memory.</li>
<li>The server runs out of memory, causing a denial-of-service condition for legitimate users.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability leads to a denial-of-service condition on the targeted Netty server. This can disrupt services, cause downtime, and impact legitimate users. Organizations using affected versions of Netty are vulnerable to this attack. Developers may have a false sense of security, believing that <code>maxAllocation</code> protects them from all decompression bombs, but are unknowingly exposed when using brotli, zstd, or snappy encodings. A trivial header modification bypasses the intended protection.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade to a patched version of Netty that addresses CVE-2026-42587.</li>
<li>Apply the recommended fix by passing <code>maxAllocation</code> to all decoder constructors, including <code>BrotliDecoder</code>, <code>SnappyFrameDecoder</code>, and <code>ZstdDecoder</code>, as outlined in the advisory.</li>
<li>For <code>BrotliDecoder</code> and <code>SnappyFrameDecoder</code>, implement <code>maxAllocation</code> parameter with the same semantics as <code>ZlibDecoder.prepareDecompressBuffer()</code>.</li>
<li>For <code>ZstdDecoder</code>, ensure that when <code>maxAllocation</code> is set, total output across all buffers is bounded.</li>
<li>Implement a network-level rule to limit the size of compressed requests based on <code>Content-Encoding</code> header and request size to mitigate potential decompression attacks even if the application is vulnerable.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>decompression-bomb</category><category>denial-of-service</category><category>netty</category><category>http</category></item></channel></rss>