{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/vendors/netty/","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-compression (\u003c= 4.2.12.Final)","netty-codec (\u003c= 4.1.132.Final)"],"_cs_severities":["medium"],"_cs_tags":["resource-exhaustion","denial-of-service","netty"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eThe Netty framework is susceptible to a resource exhaustion vulnerability in its Lz4FrameDecoder. This vulnerability stems from the decoder\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker establishes a network connection to a Netty-based server using the affected Lz4FrameDecoder.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious LZ4 frame header, setting the \u003ccode\u003edecompressedLength\u003c/code\u003e field to a large value (e.g., 32MB). The complete header can be as small as 22 bytes.\u003c/li\u003e\n\u003cli\u003eThe attacker sends the crafted header to the server.\u003c/li\u003e\n\u003cli\u003eThe Lz4FrameDecoder on the server receives the header and allocates a ByteBuf based on the attacker-controlled \u003ccode\u003edecompressedLength\u003c/code\u003e value.\u003c/li\u003e\n\u003cli\u003eThe decoder attempts to decompress the (nonexistent or minimal) compressed data, which may trigger an \u003ccode\u003eIndexOutOfBoundsException\u003c/code\u003e or other decompression error.\u003c/li\u003e\n\u003cli\u003eThe server\u0026rsquo;s memory resources are consumed by the allocated ByteBuf, even if the decompression fails.\u003c/li\u003e\n\u003cli\u003eThe attacker repeats steps 3-6 to continuously allocate memory.\u003c/li\u003e\n\u003cli\u003eThe server\u0026rsquo;s memory is exhausted, leading to 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 results in a denial-of-service (DoS) condition. An attacker can exhaust the server\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a non-vulnerable version of \u003ccode\u003eio.netty:netty-codec-compression\u003c/code\u003e (greater than 4.2.12.Final) or \u003ccode\u003eio.netty:netty-codec\u003c/code\u003e (greater than 4.1.132.Final) to patch CVE-2026-42583.\u003c/li\u003e\n\u003cli\u003eImplement per-channel and aggregate limits on incoming data and memory allocation to mitigate the impact of resource exhaustion attacks.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for unusually small LZ4 frames with excessively large declared decompressed lengths. Deploy the \u003ccode\u003eNetty Lz4 Frame Decoder Large Allocation\u003c/code\u003e Sigma rule to your SIEM to detect this pattern.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-07T00:20:35Z","date_published":"2026-05-07T00:20:35Z","id":"/briefs/2024-01-netty-lz4-resource-exhaustion/","summary":"Netty's Lz4FrameDecoder is vulnerable to resource exhaustion, where an attacker can cause excessive memory allocation by sending a small, crafted header, leading to a denial-of-service condition; this affects netty-codec-compression versions up to 4.2.12.Final and netty-codec versions up to 4.1.132.Final.","title":"Netty Lz4FrameDecoder Resource Exhaustion Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-netty-lz4-resource-exhaustion/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Netty 4.2.12.Final"],"_cs_severities":["medium"],"_cs_tags":["netty","dns","vulnerability","cache-poisoning"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eNetty, 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 \u003ccode\u003ecodec-dns\u003c/code\u003e). The vulnerability stems from the \u003ccode\u003eio.netty.handler.codec.dns.DnsCodecUtil\u003c/code\u003e 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\u0026rsquo;s DNS resolution features.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Input\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEncoding (Outbound)\u003c/strong\u003e: The application uses \u003ccode\u003eDnsCodecUtil.encodeDomainName()\u003c/code\u003e to encode the domain name into a DNS query packet without proper validation. This allows malicious domain names to be crafted.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDNS Query\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDecoding (Inbound)\u003c/strong\u003e: The application receives a DNS response containing a crafted domain name, potentially with oversized labels exceeding 63 bytes or the total 255-byte limit.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerable Decoding\u003c/strong\u003e: The \u003ccode\u003eDnsCodecUtil.decodeDomainName()\u003c/code\u003e method decodes the domain name without proper length validation, leading to unbounded StringBuilder growth if oversized labels are present.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMemory Exhaustion or Parser Confusion\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCache Poisoning or Validation Bypass\u003c/strong\u003e: If null bytes are present, DNS cache poisoning or domain validation bypass may occur.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApplication Impact\u003c/strong\u003e: 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.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s DNS resolution. A single compromised application can lead to broader network disruptions through DNS poisoning.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Netty version 4.2.13.Final or later, which addresses the input validation issues in the DNS codec.\u003c/li\u003e\n\u003cli\u003eApply input validation on the client side to sanitize domain names before they are passed to the Netty DNS codec, mitigating encoder-side attacks.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Detect Netty DNS Encoder Overlength Labels\u0026rdquo; to identify instances of overlength labels being encoded in DNS queries.\u003c/li\u003e\n\u003cli\u003eMonitor and restrict outbound DNS traffic originating from applications using Netty to known, legitimate DNS resolvers to reduce the attack surface for encoder-side exploits.\u003c/li\u003e\n\u003cli\u003eEnable detailed logging of DNS queries and responses to facilitate forensic analysis in case of suspected DNS cache poisoning or other malicious activity.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-07T00:12:47Z","date_published":"2026-05-07T00:12:47Z","id":"/briefs/2024-01-03-netty-dns-bypass/","summary":"Netty's DNS codec fails to enforce RFC 1035 domain name constraints, leading to potential DNS cache poisoning, denial-of-service, and domain validation bypass through null byte injection, overlength labels, silent truncation, and unbounded memory allocation.","title":"Netty DNS Codec Input Validation Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-03-netty-dns-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["netty-transport-native-epoll ( \u003c 4.2.13.Final)"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","netty","epoll","resource-exhaustion"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eA denial-of-service vulnerability exists in Netty\u0026rsquo;s epoll transport for versions 4.2.x up to and including 4.2.12.Final. When \u003ccode\u003eALLOW_HALF_CLOSURE\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA client establishes a TCP connection with a Netty-based server using the epoll transport.\u003c/li\u003e\n\u003cli\u003eThe server configures the connection with \u003ccode\u003eALLOW_HALF_CLOSURE\u003c/code\u003e enabled or uses the HTTP codec which can result in a half-closed state.\u003c/li\u003e\n\u003cli\u003eThe client sends a FIN packet to initiate a half-close of the TCP connection, signaling that it will no longer send data.\u003c/li\u003e\n\u003cli\u003eThe server acknowledges the FIN and marks the input side of the channel as shutdown.\u003c/li\u003e\n\u003cli\u003eThe client abruptly terminates the connection by sending a RST packet (e.g., by closing the socket with \u003ccode\u003eSO_LINGER=0\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDue to a flaw in Netty\u0026rsquo;s epoll transport, the server fails to process the \u003ccode\u003eEPOLLERR\u003c/code\u003e or \u003ccode\u003eEPOLLHUP\u003c/code\u003e event triggered by the RST.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003echannelInactive\u003c/code\u003e event is never fired, leaving the channel in a stale state.\u003c/li\u003e\n\u003cli\u003eAn attacker repeats this process, accumulating stale channels and exhausting server resources, potentially leading to a CPU busy-loop and a denial-of-service condition.\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 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\u0026rsquo;s resource capacity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Netty version 4.2.13.Final or later to patch CVE-2026-42577 and resolve the vulnerability.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, configure idle timeouts on connections to limit the lifetime of stale channels, mitigating the resource exhaustion impact.\u003c/li\u003e\n\u003cli\u003eMonitor CPU utilization of Netty event loop threads. Investigate processes with high CPU usage for extended periods to identify potential exploitation of this vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on new TCP connections from individual source IPs to reduce the effectiveness of connection exhaustion attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-06T23:10:41Z","date_published":"2026-05-06T23:10:41Z","id":"/briefs/2024-01-netty-dos/","summary":"Netty's epoll transport fails to properly close TCP connections that receive a RST after a half-close, leading to resource exhaustion and potential CPU busy-loops, impacting service availability.","title":"Netty epoll Transport Denial of Service via RST on Half-Closed TCP Connection","url":"https://feed.craftedsignal.io/briefs/2024-01-netty-dos/"},{"_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/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["netty-codec-http3 (\u003c= 4.2.12.Final)"],"_cs_severities":["medium"],"_cs_tags":["netty","http3","qpack","denial-of-service","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eA vulnerability exists in Netty\u0026rsquo;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 \u003ccode\u003eio.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker crafts an HTTP/3 HEADERS frame with a malicious QPACK section.\u003c/li\u003e\n\u003cli\u003eThe QPACK section is designed to trigger the non-Huffman branch of \u003ccode\u003eio.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe 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.\u003c/li\u003e\n\u003cli\u003eThe Netty server receives the malicious HTTP/3 HEADERS frame.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eQpackDecoder\u003c/code\u003e attempts to allocate a byte array of the size specified in the malicious header using \u003ccode\u003enew byte[length]\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDue to the missing length validation, the server allocates a potentially gigabyte-sized byte array.\u003c/li\u003e\n\u003cli\u003eThe server experiences high memory consumption and potential resource exhaustion.\u003c/li\u003e\n\u003cli\u003eThe server slows down, stalls, or crashes due to the excessive memory allocation.\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 denial-of-service condition, where the server becomes unresponsive or crashes. This affects applications using the vulnerable versions of \u003ccode\u003enetty-codec-http3\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of \u003ccode\u003enetty-codec-http3\u003c/code\u003e that addresses the vulnerability.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule below to detect attempts to exploit this vulnerability by monitoring for unusually large memory allocations associated with HTTP/3 header decoding.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on HTTP/3 requests to mitigate the impact of a large number of malicious requests.\u003c/li\u003e\n\u003cli\u003eMonitor server resource utilization (CPU, memory) for unusual spikes that may indicate exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-netty-http3-qpack/","summary":"A vulnerability in Netty's HTTP/3 QPACK decoder allows an attacker to cause a denial of service by sending a crafted HTTP/3 header that triggers excessive memory allocation, leading to a server crash.","title":"Netty HTTP/3 QPACK Literal Unbounded Allocation Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-01-netty-http3-qpack/"}],"language":"en","title":"CraftedSignal Threat Feed — Netty","version":"https://jsonfeed.org/version/1.1"}