CVE-2026-42577: Netty Epoll Transport DoS Vulnerability

CVE-2026-42577 Overview

CVE-2026-42577 affects Netty, an asynchronous, event-driven network application framework widely used in Java server applications. The vulnerability resides in Netty's epoll transport, which fails to detect and close TCP connections that receive a RST packet after being half-closed. Affected versions range from 4.2.0.Final through 4.2.12.Final, with 4.2.13.Final containing the fix. The defect produces stale channels that are never cleaned up. In certain code paths, the event loop thread enters a 100% CPU busy-loop, exhausting host resources. The issue is tracked under [CWE-772] (Missing Release of Resource after Effective Lifetime).

Critical Impact

Remote attackers can trigger CPU exhaustion and channel leaks in Netty-based servers by sending crafted TCP RST packets against half-closed connections, degrading or halting service availability.

Affected Products

• Netty 4.2.0.Final through 4.2.12.Final (epoll transport)
• Java applications using io.netty.channel.epoll.EpollIoHandler on Linux
• Server frameworks and middleware that depend on Netty's native epoll transport

Discovery Timeline

• 2026-05-13 - CVE-2026-42577 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42577

Vulnerability Analysis

The flaw resides in Netty's native Linux epoll transport implementation. When a peer half-closes a TCP connection and the local side later receives a RST, the epoll handler fails to deregister the corresponding file descriptor. The kernel continues to deliver EPOLLHUP and EPOLLERR notifications for that descriptor. Netty has no remaining interest set to process these events, so the event loop wakes repeatedly and never makes progress. This produces stale Channel objects that consume memory and, in affected code paths, drives one event loop thread to sustained 100% CPU utilization. The condition is reachable over the network without authentication and impacts service availability.

Root Cause

The root cause is missing release of a kernel resource after its effective lifetime. The EpollIoHandler registration logic did not handle the case where the desired interest mask becomes zero. With no interest bits set, the descriptor should be removed from the epoll instance with EPOLL_CTL_DEL. Instead, it remained registered, and the kernel kept reporting EPOLLHUP/EPOLLERR indefinitely.

Attack Vector

A remote unauthenticated attacker can establish a TCP connection to a Netty-based service, perform a half-close, and then trigger a RST to leave the server-side descriptor in the unrecoverable state. Repeating the pattern across many connections leaks channels and saturates event loop threads, causing denial of service against the affected application.

// Source: https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d
// Patch in transport-classes-epoll/src/main/java/io/netty/channel/epoll/EpollIoHandler.java
                         case Cancelled:
                             return -1;
                         case Pending:
+                            if (epollIoOps.value == EpollIoOps.NONE.value) {
+                                // 0 is a special value that basically means we should remove the registration.
+                                // As we did not add the fd yet we should just return.
+                                return 0;
+                            }
                             Native.epollCtlAdd(epollFd.intValue(), handle.fd().intValue(), epollIoOps.value);
                             state = RegistrationState.Added;
+                            return epollIoOps.value;
                         case Added:
+                            if (epollIoOps.value == EpollIoOps.NONE.value) {
+                                // 0 means there is nothing to handle anymore, unregister the fd as otherwise
+                                // we might get notified forever because of EPOLLHUP / EPOLLERR.
+                                Native.epollCtlDel(epollFd.intValue(), handle.fd().intValue());
+                                return 0;
+                            }
                             Native.epollCtlMod(epollFd.intValue(), handle.fd().intValue(), epollIoOps.value);
                             return epollIoOps.value;

The patch introduces a new EpollIoOps.NONE sentinel and calls Native.epollCtlDel when the interest set drops to zero, ensuring the descriptor is removed from the epoll fd.

Detection Methods for CVE-2026-42577

Indicators of Compromise

• Sustained 100% CPU utilization on a single Netty EventLoop thread without corresponding application throughput.
• Growing count of open file descriptors and Channel instances in the JVM despite stable or declining client load.
• Repeated EPOLLHUP or EPOLLERR events visible in strace or kernel tracing against a Netty server process.

Detection Strategies

• Inventory application dependencies for Netty versions between 4.2.0.Final and 4.2.12.Final using software composition analysis tools.
• Profile Netty event loops with JFR or async-profiler and look for hot stacks anchored in EpollIoHandler.run with no useful work performed.
• Correlate TCP RST patterns at the network layer with simultaneous CPU spikes on Netty-backed services.

Monitoring Recommendations

• Alert on per-thread CPU utilization above a sustained threshold for Netty event loop threads.
• Track the open file descriptor count and JVM Channel metrics over time and flag monotonic growth.
• Capture and review network telemetry for unusual sequences of half-close followed by RST from the same source.

How to Mitigate CVE-2026-42577

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or later across all affected services and rebuild dependent artifacts.
• Identify shaded or relocated copies of Netty inside fat JARs and replace them with the patched version.
• Restart Netty-based services to release any already-leaked descriptors and stale channels.

Patch Information

The fix is in Netty 4.2.13.Final, delivered through commit 0ec3d97 and pull request netty/netty#16689. Full details are published in GitHub Security Advisory GHSA-rwm7-x88c-3g2p. The patch adds an EpollIoOps.NONE value and ensures Native.epollCtlDel is invoked when the interest mask becomes zero.

Workarounds

• Switch the transport from epoll to NIO where performance requirements allow, since the issue is specific to the native epoll transport.
• Place a reverse proxy or load balancer in front of Netty services to terminate TCP and absorb abusive half-close/RST sequences.
• Apply rate limiting and connection caps at the network edge to bound the number of stale channels a single source can create.

# Maven dependency override to enforce the patched Netty version
mvn dependency:tree -Dincludes=io.netty
# Update pom.xml to use Netty 4.2.13.Final or later
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-transport-native-epoll</artifactId>
#   <version>4.2.13.Final</version>
# </dependency>