CVE-2026-42577: Netty: epoll transport denial of service via RST on half-closed TCP connection
Summary
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.
Affected versions
All versions of 4.2.x netty-transport-native-epoll up to and including 4.2.12.Final
Fixed in
4.2.13.Final (fix merged into the 4.2 branch via #16689; release not yet cut as of 2026-04-25).
Severity
Medium — Denial of Service (resource exhaustion / CPU spin)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Description
When a TCP connection using Netty's epoll transport has ALLOWHALFCLOSURE enabled (or is in a half-closed state via the HTTP codec), and the remote peer:
1. Sends a FIN (half-close), causing the server to mark the input as shutdown, then 2. Sends a RST (e.g. by closing with SOLINGER=0)
the server-side channel is never closed. This happens because:
- epollOutReady() is a no-op when there is no pending flush. - epollInReady() short-circuits via shouldBreakEpollInReady() because input is already marked as shutdown. - The EPOLLERR/EPOLLHUP error condition is therefore never processed, and channelInactive is never fired.
Depending on the Netty version and configuration, this results in:
- Stale channels: The connection is never closed or deregistered. An unauthenticated remote attacker can repeat the sequence to accumulate stale connections, exhausting file descriptors, memory, or connection-count limits. - CPU busy-loop: In code paths where clearEpollIn0() is not called during the ChannelInputShutdownReadComplete event, epollwait returns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.
Mitigation
- Upgrade to 4.2.13.Final when released (or build from the 4.2 branch at commit 0ec3d97). - If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.
Resources
- Issue: https://github.com/netty/netty/issues/16683 - Fix: https://github.com/netty/netty/pull/16689
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/io.netty:netty-transport-native-epollto a version that resolves this vulnerability.Fixed in 4.2.13.Final - Upgrade
Upgrade
netty-transport-native-epollto a version that resolves this vulnerability.Fixed in 4.2.13.FinalPatch #16689 - Compensating control
If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-42577?
The severity of CVE-2026-42577 is classified as high due to the potential for CPU busy-looping and resource exhaustion.
How do I fix CVE-2026-42577?
To fix CVE-2026-42577, upgrade to a patched version of Netty that is above 4.2.13.Final.
What versions of Netty are affected by CVE-2026-42577?
All versions of Netty 4.2.x up until 4.2.13.Final are affected by CVE-2026-42577.
What is the impact of CVE-2026-42577 on my application?
CVE-2026-42577 can lead to stale channels and a 100% CPU busy-loop in the event loop thread, affecting application performance.
Is there a workaround for CVE-2026-42577 if I cannot immediately upgrade?
There is no official workaround for CVE-2026-42577, so upgrading to a fixed version is recommended as the primary solution.