Netty — CraftedSignal Threat Feed

Netty HttpContentDecompressor Brotli/Zstd/Snappy Decompression Bomb Vulnerability

hello@craftedsignal.io — Thu, 07 May 2026 00:46:35 +0000

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

The attacker identifies a Netty-based HTTP server that uses HttpContentDecompressor or DelegatingDecompressorFrameListener with a configured maxAllocation value.
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.
The attacker sets the Content-Encoding HTTP header to br, zstd, or snappy.
The attacker sends an HTTP POST request to the vulnerable server, including the malicious compressed payload in the request body.
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).
Because the maxAllocation is not enforced for these decoders, decompression proceeds without memory limits.
The decoder allocates memory to store the decompressed data, which rapidly consumes available memory.
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.

Netty Lz4FrameDecoder Resource Exhaustion Vulnerability

hello@craftedsignal.io — Thu, 07 May 2026 00:20:35 +0000

The Netty framework is susceptible to a resource exhaustion vulnerability in its Lz4FrameDecoder. This vulnerability stems from the decoder’s reliance on header fields for buffer sizing. An attacker can exploit this by sending a minimal (22-byte) crafted header that specifies a large decompressed length (up to 32MB per block). This forces the server to allocate an unnecessarily large ByteBuf before the LZ4 decompression even occurs, consuming significant memory resources. The vulnerability affects netty-codec-compression versions up to 4.2.12.Final and netty-codec versions up to 4.1.132.Final. By repeatedly sending these malicious headers, an attacker can exhaust server memory, leading to a denial-of-service condition. This is especially critical in environments where Netty is used to handle network communications and where untrusted clients are allowed to connect.

Attack Chain

The attacker establishes a network connection to a Netty-based server using the affected Lz4FrameDecoder.
The attacker crafts a malicious LZ4 frame header, setting the decompressedLength field to a large value (e.g., 32MB). The complete header can be as small as 22 bytes.
The attacker sends the crafted header to the server.
The Lz4FrameDecoder on the server receives the header and allocates a ByteBuf based on the attacker-controlled decompressedLength value.
The decoder attempts to decompress the (nonexistent or minimal) compressed data, which may trigger an IndexOutOfBoundsException or other decompression error.
The server’s memory resources are consumed by the allocated ByteBuf, even if the decompression fails.
The attacker repeats steps 3-6 to continuously allocate memory.
The server’s memory is exhausted, leading to a denial-of-service condition for legitimate users.

Impact

Successful exploitation of this vulnerability results in a denial-of-service (DoS) condition. An attacker can exhaust the server’s memory resources by sending a series of small, malicious requests. The number of victims would depend on the deployment of the Netty framework and the exposure of vulnerable services to untrusted clients. The sectors most affected are those relying on Netty for network communication, such as messaging platforms, application servers, and data streaming services. If the attack succeeds, the affected service becomes unavailable, disrupting normal operations and potentially leading to data loss or service outages.

Recommendation

Upgrade to a non-vulnerable version of io.netty:netty-codec-compression (greater than 4.2.12.Final) or io.netty:netty-codec (greater than 4.1.132.Final) to patch CVE-2026-42583.
Implement per-channel and aggregate limits on incoming data and memory allocation to mitigate the impact of resource exhaustion attacks.
Monitor network traffic for unusually small LZ4 frames with excessively large declared decompressed lengths. Deploy the Netty Lz4 Frame Decoder Large Allocation Sigma rule to your SIEM to detect this pattern.

Netty DNS Codec Input Validation Bypass Vulnerability

hello@craftedsignal.io — Thu, 07 May 2026 00:12:47 +0000

Netty, a widely used asynchronous event-driven network application framework, contains a critical input validation bypass vulnerability within its DNS codec (versions 4.2.12.Final and prior using codec-dns). The vulnerability stems from the io.netty.handler.codec.dns.DnsCodecUtil component, which inadequately validates domain name inputs during both encoding and decoding. This failure to adhere to RFC 1035 standards enables attackers to inject null bytes, create overlength labels, silently truncate domain names, and trigger unbounded memory allocation. Exploitation can lead to DNS cache poisoning, domain validation bypass, denial of service, and the generation of malformed DNS packets. This bidirectional attack surface allows for malicious DNS responses and user-influenced hostnames to be leveraged against applications using Netty’s DNS resolution features.

Attack Chain

Initial Input: A Netty application receives a DNS query or is configured to resolve a domain name provided by a user, which may contain malicious elements such as null bytes or exceed length restrictions.
Encoding (Outbound): The application uses DnsCodecUtil.encodeDomainName() to encode the domain name into a DNS query packet without proper validation. This allows malicious domain names to be crafted.
DNS Query: The crafted DNS query is sent to a DNS server. If the domain name contains null bytes, different DNS servers may interpret the domain differently, potentially leading to cache poisoning.
Decoding (Inbound): The application receives a DNS response containing a crafted domain name, potentially with oversized labels exceeding 63 bytes or the total 255-byte limit.
Vulnerable Decoding: The DnsCodecUtil.decodeDomainName() method decodes the domain name without proper length validation, leading to unbounded StringBuilder growth if oversized labels are present.
Memory Exhaustion or Parser Confusion: Excessive memory allocation occurs due to large labels, potentially causing a denial-of-service. Alternatively, overlength labels may be misinterpreted as compression pointers, causing parser confusion.
Cache Poisoning or Validation Bypass: If null bytes are present, DNS cache poisoning or domain validation bypass may occur.
Application Impact: Downstream processes that handle the decoded domain names (e.g., certificate validators, URL parsers) may crash or exhibit unexpected behavior due to the malformed domain names.

Impact

Successful exploitation of this vulnerability can have severe consequences, including DNS cache poisoning, enabling attackers to redirect traffic to malicious servers. Domain validation bypass can allow attackers to impersonate legitimate domains. The unbounded memory allocation in the decoder can lead to denial-of-service conditions, impacting the availability of applications relying on Netty’s DNS resolution. A single compromised application can lead to broader network disruptions through DNS poisoning.

Recommendation

Upgrade to Netty version 4.2.13.Final or later, which addresses the input validation issues in the DNS codec.
Apply input validation on the client side to sanitize domain names before they are passed to the Netty DNS codec, mitigating encoder-side attacks.
Deploy the Sigma rule “Detect Netty DNS Encoder Overlength Labels” to identify instances of overlength labels being encoded in DNS queries.
Monitor and restrict outbound DNS traffic originating from applications using Netty to known, legitimate DNS resolvers to reduce the attack surface for encoder-side exploits.
Enable detailed logging of DNS queries and responses to facilitate forensic analysis in case of suspected DNS cache poisoning or other malicious activity.

Netty epoll Transport Denial of Service via RST on Half-Closed TCP Connection

hello@craftedsignal.io — Wed, 06 May 2026 23:10:41 +0000

A denial-of-service vulnerability exists in Netty’s epoll transport for versions 4.2.x up to and including 4.2.12.Final. When ALLOW_HALF_CLOSURE is enabled (or when using the HTTP codec), if a remote peer sends a FIN (half-close) followed by a RST, the server-side channel is not properly closed. This can lead to stale channels accumulating, exhausting file descriptors, memory, or connection count limits. In certain code paths, it can also trigger a 100% CPU busy-loop in the event loop thread, starving other connections. This vulnerability allows an unauthenticated remote attacker to cause a denial of service. The issue is resolved in version 4.2.13.Final.

Attack Chain

A client establishes a TCP connection with a Netty-based server using the epoll transport.
The server configures the connection with ALLOW_HALF_CLOSURE enabled or uses the HTTP codec which can result in a half-closed state.
The client sends a FIN packet to initiate a half-close of the TCP connection, signaling that it will no longer send data.
The server acknowledges the FIN and marks the input side of the channel as shutdown.
The client abruptly terminates the connection by sending a RST packet (e.g., by closing the socket with SO_LINGER=0).
Due to a flaw in Netty’s epoll transport, the server fails to process the EPOLLERR or EPOLLHUP event triggered by the RST.
The channelInactive event is never fired, leaving the channel in a stale state.
An attacker repeats this process, accumulating stale channels and exhausting server resources, potentially leading to a CPU busy-loop and a denial-of-service condition.

Impact

Successful exploitation of this vulnerability can lead to a denial-of-service condition. An unauthenticated remote attacker can exhaust server resources like file descriptors, memory, and connection limits, or trigger a CPU busy-loop. This can render the affected Netty-based service unavailable, impacting legitimate users. The number of potential victims depends on the scale of the deployment and the server’s resource capacity.

Recommendation

Upgrade to Netty version 4.2.13.Final or later to patch CVE-2026-42577 and resolve the vulnerability.
If upgrading is not immediately feasible, configure idle timeouts on connections to limit the lifetime of stale channels, mitigating the resource exhaustion impact.
Monitor CPU utilization of Netty event loop threads. Investigate processes with high CPU usage for extended periods to identify potential exploitation of this vulnerability.
Implement rate limiting on new TCP connections from individual source IPs to reduce the effectiveness of connection exhaustion attacks.

Netty HttpClientCodec Response Desynchronization Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 18:22:00 +0000

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

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

Netty HTTP/3 QPACK Literal Unbounded Allocation Vulnerability

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A vulnerability exists in Netty’s HTTP/3 QPACK decoder (versions 4.2.12.Final and earlier) that can be exploited to cause a denial-of-service (DoS) condition. The vulnerability stems from the io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral function, which allocates memory for HTTP/3 headers based on lengths provided in the header itself, without properly validating that the declared length corresponds to available data. A malicious actor can craft a small HTTP/3 HEADERS frame containing a QPACK section that decodes to a large non-Huffman name length, causing the server to allocate a large byte array (on the order of a gigabyte). This can exhaust server memory, leading to performance degradation or a complete crash.

Attack Chain

The attacker crafts an HTTP/3 HEADERS frame with a malicious QPACK section.
The QPACK section is designed to trigger the non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral.
The attacker sets a very large length value for a string literal within the QPACK section. The encoding allows a large length to be expressed in few bytes.
The Netty server receives the malicious HTTP/3 HEADERS frame.
The QpackDecoder attempts to allocate a byte array of the size specified in the malicious header using new byte[length].
Due to the missing length validation, the server allocates a potentially gigabyte-sized byte array.
The server experiences high memory consumption and potential resource exhaustion.
The server slows down, stalls, or crashes due to the excessive memory allocation.

Impact

Successful exploitation of this vulnerability can lead to a denial-of-service condition, where the server becomes unresponsive or crashes. This affects applications using the vulnerable versions of netty-codec-http3. A single crafted HTTP/3 HEADERS frame can trigger gigabytes of memory allocation, making the server susceptible to resource exhaustion under relatively low request volumes. This can disrupt services, impacting availability and potentially leading to data loss or corruption.

Recommendation

Upgrade to a patched version of netty-codec-http3 that addresses the vulnerability.
Deploy the Sigma rule below to detect attempts to exploit this vulnerability by monitoring for unusually large memory allocations associated with HTTP/3 header decoding.
Implement rate limiting on HTTP/3 requests to mitigate the impact of a large number of malicious requests.
Monitor server resource utilization (CPU, memory) for unusual spikes that may indicate exploitation attempts.