CVE-2022-41881

codec-haproxy: HAProxyMessageDecoder Stack Exhaustion DoS

Netty project is an event-driven asynchronous network application framework. In versions prior to 4.1.86.Final, a StackOverflowError can be raised when parsing a malformed crafted message due to an infinite recursion. This issue is patched in version 4.1.86.Final. There is no workaround, except using a custom HaProxyMessageDecoder.

CVSS 3.1 · 5.3 Medium EPSS 1.6% KEV · Not listed

Vendors

Debian Netty Redhat

Products

Debian Linux Netty Camel Quarkus and 11 more

CVE-2026-50009

Netty QUIC stateless reset token material exposed through header-visible connection IDs

Netty is a network application framework for development of protocol servers and clients. Prior to version 4.2.15.Final, Netty QUIC exposes the stateless reset token on the network path when using the default HMAC-based connection-ID and stateless-reset-token generators. The reset token for the server's current source connection ID can be derived from bytes that appear as the connection ID in QUIC headers after a source-CID rotation. An on-path attacker observing the headers can use the token to perform a Denial of Service by sending a spoofed Stateless Reset packet. Version 4.2.15.Final patches the issue.

CVSS 3.1 · 4.8 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-50020

Netty's HttpObjectDecoder skips arbitrary initial control characters when only initial CRLF characters are permitted

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, before reading the first request-line, `HttpObjectDecoder` skips every byte for which `Character.isISOControl(b)` is `true` (0x00–0x1F and 0x7F) as well as all whitespace. RFC 9112 §2.2 only asks servers to ignore empty CRLF lines preceding the request-line — a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds. Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes significantly beyond this, and can be exploited for request-boundary confusion in pipelined or multiplexed transports where a front-end component treats those bytes differently. Versions 4.1.135.Final and 4.2.15.Final patch the issue.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-50560

Netty susceptible to HTTP/2 Reset Attack with different on-the-wire signature

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty HTTP/2 max header size handling produces an attack similar to HTTP/2 Rapid Reset. There is a setting in the http2 specification called `SETTINGS_MAX_HEADER_LIST_SIZE`. When a client sends that setting to Netty, it appears that Netty will behave as follows: read the request; proxy the request to the origin; attempt to produce a response; and create an exception while writing the headers for the response. Functionally, this should be similar to the http2 reset attack, but with a different on-the-wire signature. Versions 4.1.135.Final and 4.2.15.Final patch the issue.

CVSS 4.0 · 6.9 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-44892

Netty has a Vulnerable Default Configuration Which Leads to Denial of Service via Unbounded HTTP/3 Header Size

Netty is a network application framework for development of protocol servers and clients. Prior to version 4.2.15.Final, the default configuration of the `Http3ConnectionHandler` in the Netty HTTP/3 codec lacks an enforced maximum header size limit. When a peer does not explicitly specify `HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE`, the implementation defaults to an unbounded limit. This insecure default configuration allows a malicious client or server to send an enormous number of headers, leading to a memory exhaustion Denial of Service via an `OutOfMemoryError`. Version 4.2.15.Final contains a patch.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-44894

Netty's Default QUIC token handler accepts any client-supplied token

Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as 'token is valid, ODCID starts at offset 0', causing the server to call quiche_accept as if the client's address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct 'no token handler' semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-45536

Netty: Unix-socket fd receive leaks descriptors when peer sends two at once

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, netty_unix_socket_recvFd sets msg_control to `char control[CMSG_SPACE(sizeof(int))]` (line 940) — 24 bytes on 64-bit Linux. A peer-sent SCM_RIGHTS cmsg carrying two ints has cmsg_len = CMSG_LEN(8) = 24, which fits exactly with no MSG_CTRUNC, so the kernel installs both fds in the receiving process. The subsequent check `cmsg->cmsg_len == CMSG_LEN(sizeof(int))` (line 972, expected 20) fails, the branch that would read the fd is skipped, and neither installed fd is closed. The for(;;) loop calls recvmsg again (non-blocking → EAGAIN → Java maps to 0 → read loop exits normally), leaving two leaked fds per message. There is no MSG_CTRUNC handling. Reachable via Epoll/KQueue DomainSocketChannel when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS (non-default). Versions 4.1.135.Final and 4.2.15.Final patch the issue.

CVSS 3.1 · 4 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-45673

Netty: DNS Cache Poisoning due to Predictable PRNG and Default Static Source Port

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, Netty's DNS resolver uses a predictable PRNG for generating DNS transaction IDs and defaults to a static UDP source port. This combination reduces the entropy of DNS queries, enabling DNS Cache Poisoning (Kaminsky attack). Versions 4.1.135.Final and 4.2.15.Final patch the issue.

CVSS 3.1 · 6.8 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-47244

Netty HTTP/2: Advertised MAX_CONCURRENT_STREAMS are not enforced

Netty is a network application framework for development of protocol servers and clients. Prior to versions 4.1.135.Final and 4.2.15.Final, DefaultHttp2Connection.DefaultEndpoint initialises maxActiveStreams/maxStreams to Integer.MAX_VALUE, and Http2Settings never inserts SETTINGS_MAX_CONCURRENT_STREAMS by default (Http2Settings.java:305-307 only clamps a user-supplied value). Unless the application explicitly calls initialSettings().maxConcurrentStreams(n), a Netty HTTP/2 server advertises no limit and enforces none locally. Each open stream allocates a DefaultStream object, PropertyMap slots, flow-controller state and IntObjectHashMap entry; with ~2^30 permissible odd stream IDs a single TCP connection can create hundreds of thousands of long-lived stream objects. This is also the precondition for CVE-2023-44487-style Rapid-Reset amplification, where the absence of a low concurrent cap multiplies backend work. Versions 4.1.135.Final and 4.2.15.Final patch the issue.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-41207

netty-incubator-codec-ohttp's HPKEContext operations may produce empty byte[] on failures

The netty incubator codec.bhttp is a java language binary http parser. Prior to version 0.0.21.Final, HKDF_expand returns non-NULL on failure. The byte[] is filled with zeros and has no way to distinguish success from failure. Since this output is used as HKDF key material for the response AEAD, a failure silently produces an all-zero key. When EVP_HPKE_CTX_export fails it also returns an empty byte[] array filled with zeros. This byte[] feeds directly into OHttpCrypto.createResponseAEAD(...). A silent all-zero export secret would produce a deterministic, attacker-predictable AEAD key. Version 0.0.21.Final patches the issue.

CVSS 4.0 · 6.9 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty-incubator-codec-ohttp

CVE-2026-48040

netty-incubator-codec-ohttp's Incorrect Native Pointer Derivation in Pooled Direct ByteBuf Fallback Leads to Out-of-Bounds Native Memory Access

The netty incubator codec.bhttp is a java language binary http parser. The library implements Oblivious HTTP (RFC 9458) using BoringSSL's HPKE C library via JNI. When deriving native memory addresses for cryptographic operations versions prior to 0.0.22.Final provide a fallback path for direct ByteBufs that do not expose their memory address through `hasMemoryAddress()`. This fallback occurs when `sun.misc.Unsafe` is unavailable to Netty — for example, when the JVM is started with `-Dio.netty.noUnsafe=true`, when a SecurityManager restricts Unsafe access, or when running on non-HotSpot JVMs. In these configurations, Netty's default `PooledByteBufAllocator` returns `PooledDirectByteBuf` instances for which `hasMemoryAddress()` returns false. Under the enabling JVM configuration, an unauthenticated network attacker can cause the OHTTP gateway to corrupt memory belonging to other concurrent connections and disclose the contents of adjacent pooled direct buffers by triggering cryptographic operations with crafted OHTTP requests. The corruption occurs regardless of whether the AEAD tag verification succeeds, as BoringSSL zeroizes the output buffer on failure. The information disclosure path provides the attacker with the encryption key needed to extract the leaked data. This violates the confidentiality and integrity of all connections sharing the same Netty buffer arena. Version 0.0.22.Final fixes the issue.

CVSS 4.0 · 6.8 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty-incubator-codec-ohttp

CVE-2026-48480

netty-incubator-codec-ohttp OHttpVersionChunkDraft's Missing Final-Chunk Enforcement Leads to Undetected Stream Truncation

The netty incubator codec.bhttp is a java language binary http parser. Prior to version 0.0.22.FInal, the codec-ohttp implementation of draft-ietf-ohai-chunked-ohttp does not verify that a cryptographically-signed final chunk was received before the outer HTTP body terminates. An on-path adversary (the OHTTP relay itself, or any MITM on the relay↔gateway or relay↔client transport) can forward a prefix of a legitimate chunked-OHTTP message—cut at a non-final chunk boundary—and close the outer body cleanly, producing no decryption error and no exception in the receiving application. Version 0.0.22.Final fixes the issue.

CVSS 4.0 · 6.6 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty-incubator-codec-ohttp

CVE-2026-42586

Netty: CRLF Injection in Netty Redis Codec Encoder

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, the Netty Redis codec encoder (RedisEncoder) writes user-controlled string content directly to the network output buffer without validating or sanitizing CRLF (\r\n) characters. Since the Redis Serialization Protocol (RESP) uses CRLF as the command/response delimiter, an attacker who can control the content of a Redis message can inject arbitrary Redis commands or forge fake responses. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

CVSS 3.1 · 6.8 Medium EPSS < 1% KEV · Not listed

Vendors

Io.netty Netty

Products

Netty-codec-redis Netty

CVE-2026-42577

Netty: epoll transport denial of service via RST on half-closed TCP connection

Netty is an asynchronous, event-driven network application framework. From 4.2.0.Final to 4.2.13.Final , Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread. This vulnerability is fixed in 4.2.13.Final.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2026-42580

Netty: HTTP Request Smuggling due to incorrect chunk size parsing

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty's chunk size parser silently overflows int, enabling request smuggling attacks. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed

Vendors

Io.netty Netty

Products

Netty-codec-http Netty

CVE-2026-42582

Netty: HTTP/3 QPACK literal unbounded allocation

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final, when decoding header blocks, the non-Huffman branch of io.netty.handler.codec.http3.QpackDecoder#decodeHuffmanEncodedLiteral may execute new byte[length] for a string literal before verifying that length bytes are actually present in the compressed field section. The wire encoding allows a very large length to be expressed in few bytes. There is no check that length <= in.readableBytes() before new byte[length]. This vulnerability is fixed in 4.2.13.Final.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Io.netty Netty

Products

Netty-codec-http3 Netty

CVE-2026-42585

Netty: HTTP Request Smuggling due to malformed Transfer-Encoding

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed

Vendors

Io.netty Netty

Products

Netty-codec-http Netty

CVE-2026-42583

Netty: Lz4FrameDecoder resource exhaustion

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed

Vendors

Io.netty Netty

Products

Netty-codec Netty-codec-compression Netty

CVE-2026-41417

Netty vulnerable to HTTP request smuggling and RTSP request injection via DefaultHttpRequest.setUri()

Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final.

CVSS 3.1 · 5.3 Medium EPSS < 1% KEV · Not listed

Vendors

Netty

Products

Netty

CVE-2025-59419

Netty netty-codec-smtp SMTP Command Injection Vulnerability Allowing Email Forgery

Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.128.Final and 4.2.7.Final, the SMTP codec in Netty contains an SMTP command injection vulnerability due to insufficient input validation for Carriage Return (\r) and Line Feed (\n) characters in user-supplied parameters. The vulnerability exists in io.netty.handler.codec.smtp.DefaultSmtpRequest, where parameters are directly concatenated into the SMTP command string without sanitization. When methods such as SmtpRequests.rcpt(recipient) are called with a malicious string containing CRLF sequences, attackers can inject arbitrary SMTP commands. Because the injected commands are sent from the server's trusted IP address, resulting emails will likely pass SPF and DKIM authentication checks, making them appear legitimate. This allows remote attackers who can control SMTP command parameters (such as email recipients) to forge arbitrary emails from the trusted server, potentially impersonating executives and forging high-stakes corporate communications. This issue has been patched in versions 4.1.129.Final and 4.2.8.Final. No known workarounds exist.

CVSS 4.0 · 5.5 Medium EPSS 1.6% KEV · Not listed

Vendors

Netty

Products

Netty