What is the CVSS score of CVE-2026-42577?

CVE-2026-42577 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Which versions of Netty are affected by CVE-2026-42577?

Netty's native epoll transport (versions 4.2.0 through 4.2.12) contains a denial-of-service vulnerability allowing unauthenticated remote attackers to exhaust server resources and trigger event-loop…. A patch is available.

How to fix or mitigate CVE-2026-42577?

Within 24 hours, identify all applications and services using netty-transport-native-epoll versions 4.2.0.Final through 4.2.12.Final and assess whether they are internet-facing or process untrusted external connections. Within 7 days, apply the vendor-released patch to upgrade to version 4.2.13.Final or later, prioritizing customer-facing and internet-exposed deployments. Within 30 days, complete patching across all affected systems, validate in staging environments for regressions, and confirm all dependent applications function normally.

Netty CVE-2026-42577

HIGH

Missing Release of Resource after Effective Lifetime (CWE-772)

2026-05-06 https://github.com/netty/netty

GHSA-rwm7-x88c-3g2p

Denial Of Service

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

Remote unauthenticated FIN+RST sequence causes availability-only DoS (A:H) with no confidentiality/integrity impact; AC:L since the deployment precondition (half-closure) is not per-attack complexity.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jul 23, 2026 - 23:04 vuln.today

Analysis Generated

Jul 23, 2026 - 23:04 vuln.today

CVE Published

May 06, 2026 - 23:10 nvd

HIGH 7.5

DescriptionGitHub Advisory

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 ALLOW_HALF_CLOSURE enabled (or is in a half-closed state via the HTTP codec), and the remote peer:

Sends a FIN (half-close), causing the server to mark the input as shutdown, then
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).
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

AnalysisAI

Denial of service in Netty's native epoll transport (netty-transport-native-epoll 4.2.0.Final through 4.2.12.Final) lets an unauthenticated remote peer leave server-side channels permanently stuck by sending a FIN to half-close a connection and then a RST. Because the EPOLLERR/EPOLLHUP condition is never processed once input is marked shut down, channelInactive never fires, so connections leak and, in code paths where clearEpollIn0() is skipped, the event-loop thread spins at 100% CPU and starves every other multiplexed connection. There is no public exploit identified at time of analysis, and the EPSS score is very low (0.04%, 11th percentile), consistent with a resource-exhaustion bug rather than a code-execution one.

Technical ContextAI

Netty is a high-performance asynchronous Java networking framework, and netty-transport-native-epoll is its Linux-specific JNI transport that drives sockets directly through the epoll(7) event notification interface instead of Java NIO. The bug is rooted in how Netty reacts (or fails to react) to epoll readiness events on a half-closed socket: epollOutReady() is a no-op with no pending flush, epollInReady() short-circuits through shouldBreakEpollInReady() because input is already shut down, and as a result the EPOLLERR/EPOLLHUP raised by the incoming RST is never handled. This maps to CWE-772 (Missing Release of Resource after Effective Lifetime): the file descriptor, channel object, and memory tied to the dead connection are never released. The fix (PR #16689, commit 0ec3d97) introduces an EpollIoOps.NONE sentinel that calls Native.epollCtlDel to remove the fd from the epoll set once nothing is interesting anymore, preventing the perpetual EPOLLHUP/EPOLLERR re-notification. The single affected artifact is the Maven package io.netty:netty-transport-native-epoll.

RemediationAI

Upgrade the netty-transport-native-epoll dependency to 4.2.13.Final, the fixed release; note the advisory states this release was not yet cut as of 2026-04-25, so if a tagged 4.2.13.Final is not yet available in your repository, build from the 4.2 branch at commit 0ec3d97fab376e243d328ac95fbd288ba0f6e22d (PR https://github.com/netty/netty/pull/16689) which removes the stale fd from the epoll set once no events are of interest. Because Netty is usually a transitive dependency, pin the version explicitly (for example via a Maven dependencyManagement or Gradle resolution constraint) so upstream frameworks do not pull the vulnerable range back in. If you cannot upgrade immediately, apply idle-timeout handlers on connections (e.g. an IdleStateHandler that closes read-idle channels) to cap the lifetime of stale channels and reclaim leaked file descriptors - the trade-off is that overly aggressive timeouts can prematurely close legitimate long-lived or keep-alive connections, so tune the idle window to your traffic. Where feasible, also review whether ALLOW_HALF_CLOSURE is actually required for a given pipeline, since disabling it removes the primary trigger condition.