{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/netty-codec-http--4.1.132.final/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["netty-codec-http (\u003e= 4.2.0.Alpha1, \u003c= 4.2.12.Final)","netty-codec-http2 (\u003e= 4.2.0.Alpha1, \u003c= 4.2.12.Final)","netty-codec-http (\u003c= 4.1.132.Final)","netty-codec-http2 (\u003c= 4.1.132.Final)"],"_cs_severities":["medium"],"_cs_tags":["decompression-bomb","denial-of-service","netty","http"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eThe Netty framework is susceptible to a decompression bomb vulnerability in its \u003ccode\u003eHttpContentDecompressor\u003c/code\u003e and \u003ccode\u003eDelegatingDecompressorFrameListener\u003c/code\u003e components. This flaw, present in versions up to 4.2.12.Final and 4.1.132.Final, arises because the \u003ccode\u003emaxAllocation\u003c/code\u003e parameter, intended to limit decompression buffer size, is ignored when content is encoded using Brotli (\u003ccode\u003ebr\u003c/code\u003e), Zstandard (\u003ccode\u003ezstd\u003c/code\u003e), or Snappy. An attacker can exploit this by sending a specially crafted compressed payload with a \u003ccode\u003eContent-Encoding\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies a Netty-based HTTP server that uses \u003ccode\u003eHttpContentDecompressor\u003c/code\u003e or \u003ccode\u003eDelegatingDecompressorFrameListener\u003c/code\u003e with a configured \u003ccode\u003emaxAllocation\u003c/code\u003e value.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious compressed payload designed to expand dramatically upon decompression (a \u0026ldquo;decompression bomb\u0026rdquo;). For example, a small compressed file expands to gigabytes of zeros.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eContent-Encoding\u003c/code\u003e HTTP header to \u003ccode\u003ebr\u003c/code\u003e, \u003ccode\u003ezstd\u003c/code\u003e, or \u003ccode\u003esnappy\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker sends an HTTP POST request to the vulnerable server, including the malicious compressed payload in the request body.\u003c/li\u003e\n\u003cli\u003eThe server receives the request and \u003ccode\u003eHttpContentDecompressor\u003c/code\u003e or \u003ccode\u003eDelegatingDecompressorFrameListener\u003c/code\u003e processes the request, detects the \u003ccode\u003eContent-Encoding\u003c/code\u003e, and attempts to decompress it using the corresponding decoder (\u003ccode\u003eBrotliDecoder\u003c/code\u003e, \u003ccode\u003eZstdDecoder\u003c/code\u003e, or \u003ccode\u003eSnappyFrameDecoder\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eBecause the \u003ccode\u003emaxAllocation\u003c/code\u003e is not enforced for these decoders, decompression proceeds without memory limits.\u003c/li\u003e\n\u003cli\u003eThe decoder allocates memory to store the decompressed data, which rapidly consumes available memory.\u003c/li\u003e\n\u003cli\u003eThe server runs out of memory, causing a denial-of-service condition for legitimate users.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003emaxAllocation\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of Netty that addresses CVE-2026-42587.\u003c/li\u003e\n\u003cli\u003eApply the recommended fix by passing \u003ccode\u003emaxAllocation\u003c/code\u003e to all decoder constructors, including \u003ccode\u003eBrotliDecoder\u003c/code\u003e, \u003ccode\u003eSnappyFrameDecoder\u003c/code\u003e, and \u003ccode\u003eZstdDecoder\u003c/code\u003e, as outlined in the advisory.\u003c/li\u003e\n\u003cli\u003eFor \u003ccode\u003eBrotliDecoder\u003c/code\u003e and \u003ccode\u003eSnappyFrameDecoder\u003c/code\u003e, implement \u003ccode\u003emaxAllocation\u003c/code\u003e parameter with the same semantics as \u003ccode\u003eZlibDecoder.prepareDecompressBuffer()\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eFor \u003ccode\u003eZstdDecoder\u003c/code\u003e, ensure that when \u003ccode\u003emaxAllocation\u003c/code\u003e is set, total output across all buffers is bounded.\u003c/li\u003e\n\u003cli\u003eImplement a network-level rule to limit the size of compressed requests based on \u003ccode\u003eContent-Encoding\u003c/code\u003e header and request size to mitigate potential decompression attacks even if the application is vulnerable.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-07T00:46:35Z","date_published":"2026-05-07T00:46:35Z","id":"/briefs/2026-05-netty-decompression-bomb/","summary":"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.","title":"Netty HttpContentDecompressor Brotli/Zstd/Snappy Decompression Bomb Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-netty-decompression-bomb/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["netty-codec-http (\u003e= 4.2.0.Alpha1, \u003c= 4.2.12.Final)","netty-codec-http (\u003c= 4.1.132.Final)"],"_cs_severities":["high"],"_cs_tags":["netty","http","desynchronization","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eA response desynchronization vulnerability exists in Netty\u0026rsquo;s \u003ccode\u003eHttpClientCodec\u003c/code\u003e when HTTP/1.1 pipelining is enabled, HEAD requests are present in the request pipeline, and the server sends 1xx responses. This occurs because the \u003ccode\u003eHttpClientCodec\u003c/code\u003e incorrectly pairs inbound responses with outbound requests, specifically when a server sends a 1xx response followed by a 200 response with a body for a GET request, and then a 200 response for a subsequent HEAD request. The \u003ccode\u003eHttpClientCodec\u003c/code\u003e may incorrectly pair the HEAD request with the first 200 response, skipping the message body and causing subsequent responses to be parsed from the wrong offset. This can lead to data integrity issues and potentially unsafe socket reuse. The vulnerability affects Netty versions 4.2.0.Alpha1 through 4.2.12.Final and all versions up to 4.1.132.Final.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker initiates a series of HTTP/1.1 requests, including a GET request followed by a HEAD request, leveraging HTTP pipelining for efficiency.\u003c/li\u003e\n\u003cli\u003eThe malicious client sends a GET request for a resource (e.g., \u003ccode\u003e/1\u003c/code\u003e) immediately followed by a HEAD request for another resource (e.g., \u003ccode\u003e/2\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe vulnerable Netty server processes the GET request and sends a 103 Early Hints response, followed by a 200 OK response containing the body of the GET request (e.g., \u0026ldquo;hello\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eThe server then processes the HEAD request and sends a 200 OK response without a body, as is standard for HEAD requests.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eHttpClientCodec\u003c/code\u003e on the client side incorrectly pairs the HEAD request with the initial 200 OK response from the GET request, due to the intervening 103 response.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eHttpClientCodec\u003c/code\u003e skips the GET response body (\u0026ldquo;hello\u0026rdquo;) when processing the HEAD response, leaving those bytes unread on the input stream.\u003c/li\u003e\n\u003cli\u003eThe subsequent HTTP response is then parsed from the wrong offset in the input stream, leading to parsing failures or incorrect data being associated with the wrong request.\u003c/li\u003e\n\u003cli\u003eThe attacker can exploit this desynchronization to potentially inject malicious content or intercept sensitive data meant for other requests, compromising the integrity and availability of the connection.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to a loss of integrity and availability of HTTP parsing, causing incorrect or incomplete data to be processed by the client application. This can result in application errors, data corruption, or the exposure of sensitive information. Furthermore, the unsafe reuse of the socket could lead to further exploitation of the compromised connection. While the exact number of affected systems is unknown, any application relying on the vulnerable versions of Netty\u0026rsquo;s \u003ccode\u003eHttpClientCodec\u003c/code\u003e and utilizing HTTP/1.1 pipelining with HEAD requests is potentially at risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of Netty that addresses CVE-2026-42584. Specifically, upgrade beyond version 4.2.12.Final or version 4.1.132.Final.\u003c/li\u003e\n\u003cli\u003eIf upgrading Netty is not immediately feasible, consider disabling HTTP/1.1 pipelining as a temporary mitigation. This will prevent the conditions necessary for the desynchronization to occur.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Netty HttpClientCodec Response Desync Error\u003c/code\u003e to identify potential exploitation attempts by monitoring for HTTP responses with decoder failures after a series of pipelined requests.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T18:22:00Z","date_published":"2024-01-03T18:22:00Z","id":"/briefs/2024-01-netty-desync/","summary":"The Netty HttpClientCodec is vulnerable to response desynchronization when configured with HTTP/1.1 pipelining, HEAD requests, and the server sends 1xx responses, leading to a response body from one request being parsed as another and potentially unsafe socket reuse.","title":"Netty HttpClientCodec Response Desynchronization Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-netty-desync/"}],"language":"en","title":"CraftedSignal Threat Feed — Netty-Codec-Http (\u003c= 4.1.132.Final)","version":"https://jsonfeed.org/version/1.1"}