Netty-Codec-Http (>= 4.2.0.Alpha1, <= 4.2.12.Final) — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/netty-codec-http--4.2.0.alpha1--4.2.12.final/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 07 May 2026 00:46:35 +0000Netty HttpContentDecompressor Brotli/Zstd/Snappy Decompression Bomb Vulnerabilityhttps://feed.craftedsignal.io/briefs/2026-05-netty-decompression-bomb/Thu, 07 May 2026 00:46:35 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-netty-decompression-bomb/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.The Netty framework is susceptible to a decompression bomb vulnerability in its HttpContentDecompressor and DelegatingDecompressorFrameListener components. This flaw, present in versions up to 4.2.12.Final and 4.1.132.Final, arises because the maxAllocation parameter, intended to limit decompression buffer size, is ignored when content is encoded using Brotli (br), Zstandard (zstd), or Snappy. An attacker can exploit this by sending a specially crafted compressed payload with a Content-Encoding 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.

Attack Chain

  1. The attacker identifies a Netty-based HTTP server that uses HttpContentDecompressor or DelegatingDecompressorFrameListener with a configured maxAllocation value.
  2. The attacker crafts a malicious compressed payload designed to expand dramatically upon decompression (a “decompression bomb”). For example, a small compressed file expands to gigabytes of zeros.
  3. The attacker sets the Content-Encoding HTTP header to br, zstd, or snappy.
  4. The attacker sends an HTTP POST request to the vulnerable server, including the malicious compressed payload in the request body.
  5. The server receives the request and HttpContentDecompressor or DelegatingDecompressorFrameListener processes the request, detects the Content-Encoding, and attempts to decompress it using the corresponding decoder (BrotliDecoder, ZstdDecoder, or SnappyFrameDecoder).
  6. Because the maxAllocation is not enforced for these decoders, decompression proceeds without memory limits.
  7. The decoder allocates memory to store the decompressed data, which rapidly consumes available memory.
  8. The server runs out of memory, causing a denial-of-service condition for legitimate users.

Impact

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 maxAllocation 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.

Recommendation

  • Upgrade to a patched version of Netty that addresses CVE-2026-42587.
  • Apply the recommended fix by passing maxAllocation to all decoder constructors, including BrotliDecoder, SnappyFrameDecoder, and ZstdDecoder, as outlined in the advisory.
  • For BrotliDecoder and SnappyFrameDecoder, implement maxAllocation parameter with the same semantics as ZlibDecoder.prepareDecompressBuffer().
  • For ZstdDecoder, ensure that when maxAllocation is set, total output across all buffers is bounded.
  • Implement a network-level rule to limit the size of compressed requests based on Content-Encoding header and request size to mitigate potential decompression attacks even if the application is vulnerable.
]]>mediumadvisorydecompression-bombdenial-of-servicenettyhttpNetty HttpClientCodec Response Desynchronization Vulnerabilityhttps://feed.craftedsignal.io/briefs/2024-01-netty-desync/Wed, 03 Jan 2024 18:22:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2024-01-netty-desync/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.A response desynchronization vulnerability exists in Netty’s HttpClientCodec 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 HttpClientCodec 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 HttpClientCodec 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.

Attack Chain

  1. The attacker initiates a series of HTTP/1.1 requests, including a GET request followed by a HEAD request, leveraging HTTP pipelining for efficiency.
  2. The malicious client sends a GET request for a resource (e.g., /1) immediately followed by a HEAD request for another resource (e.g., /2).
  3. The 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., “hello”).
  4. The server then processes the HEAD request and sends a 200 OK response without a body, as is standard for HEAD requests.
  5. The HttpClientCodec 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.
  6. The HttpClientCodec skips the GET response body (“hello”) when processing the HEAD response, leaving those bytes unread on the input stream.
  7. The 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.
  8. The 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.

Impact

Successful 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’s HttpClientCodec and utilizing HTTP/1.1 pipelining with HEAD requests is potentially at risk.

Recommendation

  • Upgrade 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.
  • If 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.
  • Deploy the Sigma rule Detect Netty HttpClientCodec Response Desync Error to identify potential exploitation attempts by monitoring for HTTP responses with decoder failures after a series of pipelined requests.
]]>highadvisorynettyhttpdesynchronizationvulnerability