By vendor

Netty vulnerabilities

Known CVEs affecting Netty products, prioritized by severity, with SEC.co remediation and detection guidance.

23 published vulnerabilities

• CVE-2026-45674HIGH 8.7

  Netty, a widely-used framework for building network servers and clients, contains a DNS validation flaw that could allow attackers to trick applications into accepting forged DNS responses. Specifically, the framework fails to properly validate CNAME records—a type of DNS alias—allowing an attacker positioned on the network path or controlling a malicious DNS server to inject false domain mappings. This could redirect traffic intended for legitimate services to attacker-controlled servers, potentially exposing credentials or enabling man-in-the-middle attacks against applications built with affected Netty versions.

• CVE-2026-47691HIGH 8.7

  Netty, a widely-used framework for building networked applications, contains a DNS cache poisoning vulnerability in how it validates nameserver records. An attacker who controls an authoritative nameserver for a subdomain can trick Netty into caching false DNS records for parent domains—such as the entire `.co.uk` domain. This happens because Netty's validation logic is too permissive: it accepts nameserver claims from subdomains without properly checking whether those subdomains should actually be trusted to answer queries about their parents. Once the cache is poisoned, all future DNS lookups under the parent domain serve the attacker's malicious responses.

• CVE-2026-44249HIGH 8.1

  Netty is a widely-used Java networking framework that powers many protocol servers and clients. A flaw in how it filters IPv6 traffic has been discovered: the masking logic in the IPv6 subnet filtering rules is broken, allowing attackers to craft IP addresses that appear to bypass intended network access controls. If your application relies on Netty to restrict traffic to specific IPv6 subnets, an attacker could send requests from addresses that should have been blocked, potentially gaining unauthorized access to protected services.

• CVE-2026-44250HIGH 7.5

  Netty's Redis codec library has a denial-of-service vulnerability where attackers can craft specially formed Redis messages with deeply nested array structures. When processed, these payloads force the affected server to create and hold vast numbers of internal state objects, consuming memory until the application crashes with an OutOfMemoryError. This impacts applications using Netty's Redis protocol handling before specific patch versions.

• CVE-2026-44890HIGH 7.5

  Netty's Redis codec (the component that reads and interprets Redis protocol messages) has a memory exhaustion vulnerability. An attacker can send malformed Redis messages across many connections to deliberately exhaust the server's direct memory buffer pool, causing an OutOfDirectMemoryError. This denies service to legitimate users. The flaw exists in Netty versions before 4.1.135.Final and 4.2.15.Final, which include fixes.

• CVE-2026-44892HIGH 7.5

  Netty, a widely-used Java framework for building network applications, has a flaw in its HTTP/3 implementation that fails to enforce limits on the size of request headers. An attacker can exploit this by sending an extremely large number of headers, causing the affected application to consume excessive memory and crash. This denial-of-service vulnerability affects versions prior to 4.2.15.Final and has a CVSS score of 7.5 (HIGH). The fix is available in version 4.2.15.Final and later.

• CVE-2026-44893HIGH 7.5

  Netty's HAProxy protocol decoder has a resource leak vulnerability triggered by malformed protocol messages. When an attacker sends a specially crafted HAProxy TLV (Type-Length-Value) structure with an undersized length field, the decoder attempts to read data beyond the declared bounds. The exception that follows bypasses the error handler, leaving memory buffers permanently unreleased. This cumulates over repeated malicious messages, exhausting available memory and crashing the application.

• CVE-2026-44894HIGH 7.5

  Netty versions prior to 4.2.15.Final contain a flaw in their default token validation logic for QUIC connections. When an application uses Netty's NoQuicTokenHandler (the built-in fallback when no custom handler is configured), the server incorrectly treats unauthenticated tokens as valid. An attacker can exploit this by sending a specially crafted QUIC Initial packet with a spoofed victim IP address and arbitrary token bytes. The server will then bypass its normal traffic rate-limiting safeguards and send full-size handshake responses (including certificates) toward the spoofed IP without restriction. This enables a reflection-based amplification attack where the attacker uses your Netty server to overwhelm a victim with QUIC handshake traffic.

• CVE-2026-45416HIGH 7.5

  Netty, a widely-used Java framework for building network applications, contains a memory exhaustion vulnerability in its TLS handshake handler. When processing incoming TLS ClientHello messages, the framework can be tricked into allocating extremely large buffers—up to 16 megabytes or more—without proper validation. An attacker sending specially crafted TLS requests can exhaust server memory and cause denial of service. The issue affects Netty versions before 4.1.135.Final and 4.2.15.Final and is most dangerous when the framework is used with common SNI (Server Name Indication) handler configurations that disable safeguards by default.

• CVE-2026-46340HIGH 7.5

  Netty is a widely-used Java framework for building networked applications. A flaw in the SCTP (Stream Control Transmission Protocol) transport component allows a remote attacker to exhaust a server's memory by sending fragmented messages that never complete. Rather than consolidating fragments efficiently, the code creates an exponentially deeper chain of buffer wrappers for each new piece, and there's no limit on how many fragments or how many separate data streams an attacker can use. This lets someone crash or severely degrade a Netty-based SCTP server with relatively small amounts of traffic.

• CVE-2026-48006HIGH 7.5

  Netty's Redis message aggregator has a memory leak that can crash applications. When a Redis client closes its connection mid-request, the handler doesn't clean up buffered data, leaving memory fragments locked in the heap. Attackers can exploit this by repeatedly opening and closing connections, slowly poisoning the shared memory pool until the entire application runs out of buffer space and fails to handle new network traffic.

• CVE-2026-48059HIGH 7.5

  Netty, a widely-used Java framework for building networked applications, contains a memory leak in its HAProxy PROXY protocol v2 decoder. When a client sends a specially crafted but valid header containing nested SSL metadata records, the decoder fails to properly release the underlying memory buffer. This happens silently—no errors are reported, the connection appears to handle normally, and the leak accumulates with each affected connection. Over time, this can exhaust server memory and cause denial of service. The issue affects Netty versions before 4.1.135.Final and 4.2.15.Final.

• CVE-2026-48748HIGH 7.5

  Netty, a widely-used Java framework for building network applications, contains a vulnerability in its HTTP/3 codec that can be exploited to exhaust server memory. An attacker can trigger the creation of an unlimited number of blocked streams, causing the affected application to run out of memory and crash. This denial-of-service condition requires no authentication and can be triggered remotely over the network. Netty versions prior to 4.2.15.Final are vulnerable.

• CVE-2026-50010HIGH 7.5

  Netty, a widely-used Java framework for building networked applications, contains a vulnerability in how it handles TLS certificate validation. When developers supply their own certificate trust manager to Netty's SSL configuration, the framework wraps it in a way that causes hostname verification to be skipped entirely—even though Netty attempts to enable it by default. An attacker positioned to intercept network traffic could exploit this to perform man-in-the-middle attacks, presenting a valid certificate for a different domain and having the client accept it without complaint.

• CVE-2026-50011HIGH 7.5

  Netty, a widely-used network framework, contains a memory exhaustion vulnerability in its Redis protocol handler. When processing incoming Redis array messages, the framework pre-allocates memory based on a count declared in the message header before validating the actual content. An attacker can send a malicious message claiming an extremely large array size, forcing the application to reserve massive amounts of memory with minimal network traffic. This causes the application to consume excessive RAM and potentially crash, denying service to legitimate users.

• CVE-2026-45673MEDIUM 6.8

  Netty, a widely-used Java framework for building network applications, has a DNS resolver flaw that makes it easier for attackers to poison DNS caches. The issue stems from two weaknesses: the framework generates DNS request IDs using a predictable random number generator, and it sends all DNS queries from the same UDP port by default. Together, these reduce the unpredictability of DNS traffic, making it feasible for an attacker to craft malicious DNS responses that get cached and served to users—a technique known as DNS Cache Poisoning or a Kaminsky attack. Patched versions 4.1.135.Final and 4.2.15.Final address both issues.

• CVE-2026-41207MEDIUM 5.3

  A vulnerability exists in Netty's binary HTTP parser (netty-incubator-codec-ohttp) where cryptographic key generation can fail silently and default to all-zero keys without raising an error. This occurs in the HKDF_expand and EVP_HPKE_CTX_export functions, which are supposed to generate random key material for encrypting HTTP responses. Instead of signaling failure, these functions return zero-filled byte arrays that are indistinguishable from legitimate keys. An attacker who understands this behavior could predict the encryption keys and decrypt sensitive response data, compromising the confidentiality of encrypted messages. The issue was resolved in version 0.0.21.Final.

• CVE-2026-47244MEDIUM 5.3

  Netty, a widely-used framework for building network applications and HTTP/2 servers, has a flaw in how it manages concurrent HTTP/2 streams. By default, Netty does not enforce a limit on the number of concurrent streams a client can open on a single connection, allowing an attacker to exhaust server resources by opening hundreds of thousands of stream objects. This vulnerability becomes especially dangerous when combined with Rapid-Reset-style attacks, where attackers can amplify their impact by rapidly opening and closing many streams.

• CVE-2026-48043MEDIUM 5.3

  Netty's HTTP/2 decompression logic has a resource leak that can exhaust memory and crash the JVM. When a remote attacker sends specially crafted HTTP/2 frames, the decompressor fails to properly release memory buffers, and repeated exploitation can lead to out-of-memory errors. This affects Netty versions before 4.1.135.Final and 4.2.15.Final.

• CVE-2026-50020MEDIUM 5.3

  Netty, a widely-used Java network framework, has a flaw in how it processes incoming HTTP requests. Before reading the first line of an HTTP request, Netty discards control characters (like NUL bytes and other non-printable characters) along with whitespace. While the HTTP specification allows servers to ignore blank lines before a request, Netty goes much further by silently accepting non-standard control bytes that RFC 9112 never intended servers to strip. In architectures where multiple components handle the same traffic—such as when requests flow through a front-end proxy to a back-end Netty service—this difference in character handling can create confusion about where one request ends and another begins, potentially allowing attackers to smuggle malicious requests or bypass security controls.

• CVE-2026-50560MEDIUM 5.3

  Netty, a widely-used Java framework for building network servers and clients, has a flaw in how it handles HTTP/2 header size limits. When a client specifies a maximum header list size via the HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE parameter, Netty can be forced into a state where it crashes while attempting to send response headers back to the client. An attacker can exploit this to repeatedly trigger these crashes, effectively denying service to legitimate users—similar in impact to the HTTP/2 Rapid Reset attack but using different network-level mechanics. The vulnerability affects Netty versions before 4.1.135.Final and 4.2.15.Final.

• CVE-2026-50009MEDIUM 4.8

  Netty, a widely-used framework for building network applications, contains a flaw in its QUIC protocol implementation that leaks sensitive reset tokens onto the network. These tokens act like cryptographic keys that allow an attacker positioned on the network path to forge denial-of-service packets and disrupt connections. The vulnerability requires the attacker to be on-path and able to observe traffic, but no special privileges or user interaction are needed. This affects Netty versions before 4.2.15.Final.

• CVE-2026-45536MEDIUM 4.0

  Netty, a widely-used Java network framework, has a file descriptor leak in its Unix domain socket implementation when handling multi-fd messages. When a peer sends a crafted control message carrying multiple file descriptors via SCM_RIGHTS, Netty's receiver allocates a fixed buffer that happens to fit the kernel's response exactly. The code then performs a validation check that fails due to the unexpected message format, causing the installed file descriptors to never be closed. Applications using DomainSocketChannel with FILE_DESCRIPTORS read mode—a non-default opt-in feature—can leak two file descriptors per malicious message received from a peer on the same host. This degrades availability by exhausting the process's file descriptor limit.