Oracle GoldenGate Security (Netty) CVEs
7 CVEs
Overview 7 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
7matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
7
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
7
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
4
57.1%
Forecast only
0
0.0%
No public exploit
3
42.9%
split by
peak 3 / month
Feb 251
No exploit published1
Medium1
not blocked1
Proof of concept only1
Mar 250
Apr 250
May 250
Jun 250
Jul 250
Aug 250
Sep 250
Oct 250
Nov 250
Dec 250
Jan 260
Feb 260
Mar 262
No exploit published2
High2
not blocked2
Proof of concept only1
No public exploit1
Apr 260
May 263
No exploit published3
High3
not blocked3
Proof of concept only2
No public exploit1
Jun 261
No exploit published1
High1
not blocked1
No public exploit1
Feb 25Apr 25Jun 25Aug 25Oct 25Dec 25Feb 26Apr 26Jun 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-45416 | High | 2026-06-12 | No exploit published | No public exploit | 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, SslClientHelloHandler.decode() reads the 24-bit TLS handshake length and, when the ClientHello does not fit in the first record, eagerly allocates `ctx.alloc().buffer(handshakeLength)` (line 161). The guard at line 140 is `handshakeLength > maxClientHelloLength && maxClientHelloLength != 0`, and the commonly-used SniHandler/AbstractSniHandler constructors (SniHandler(Mapping), SniHandler(AsyncMapping), AbstractSniHandler()) pass maxClientHelloLength=0 and handshakeTimeoutMillis=0, so the length guard is disabled and no timeout is scheduled. A 16 MiB request exceeds the default pooled chunk size and becomes a huge/unpooled allocation performed immediately. The buffer is retained in the handler until the channel closes. Versions 4.1.135.Final and 4.2.15.Final patch the issue. |
| CVE-2026-42583 | High | 2026-05-13 | No exploit published | Proof of concept only | 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. |
| CVE-2026-42582 | High | 2026-05-13 | No exploit published | Proof of concept only | 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. |
| CVE-2026-42577 | High | 2026-05-13 | No exploit published | No public exploit | 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. |
| CVE-2026-33871 | High | 2026-03-27 | No exploit published | No public exploit | Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server's lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue. |
| CVE-2026-33870 | High | 2026-03-27 | No exploit published | Proof of concept only | Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks. Versions 4.1.132.Final and 4.2.10.Final fix the issue. |
| CVE-2025-25193 | Medium | 2025-02-10 | No exploit published | Proof of concept only | Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. A similar issue was previously reported as CVE-2024-47535. This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. Commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 contains an updated fix. |