Answer in brief
CVE-2026-42577 records a High severity (CVSS 7.5) vulnerability in Netty epoll transport denial of service via RST on half-closed TCP connection. The current sources do not mark it as known exploited. The current feed maps io.netty:netty-transport-classes-epoll (maven). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps io.netty:netty-transport-classes-epoll (maven). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| io.netty:netty-transport-classes-epollmaven | >=4.2.0.Final <4.2.13.Final | 4.2.13.Final |
Published upstream
May 6, 2026
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Aug 8, 2026
## 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-classes-epoll` up to and including 4.2.12.Final ## Fixed in 4.2.13.Final (fix merged into the `4.2` branch via [#16689](https://github.com/netty/netty/pull/16689); release not yet cut as of 2026-04-25). ## Severity **Medium** — Denial of Service (resource exhaustion / CPU spin) **CVSS:** 3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - **7.5** **CWE:** CWE-772: Missing Release of Resource after Effective Lifetime ## Description When a TCP connection using Netty's epoll transport has `ALLOW_HALF_CLOSURE` 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 `SO_LINGER=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, `epoll_wait` 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`](https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d)). - If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels. ## References - Issue: https://github.com/netty/netty/issues/16683 - Fix: https://github.com/netty/netty/pull/16689
Quoted source text, attributed separately from HOL analysis.