Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕ Maven

GHSA-rwm7-x88c-3g2p

HIGH

GHSA-rwm7-x88c-3g2p is a high-severity (CVSS 7.5) vulnerability in io.netty:netty-transport-classes-epoll. O3 Security confirms whether GHSA-rwm7-x88c-3g2p is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Netty epoll transport denial of service via RST on half-closed TCP connection

Also known asCVE-2026-42577
Published
May 6, 2026
Updated
Jul 24, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
☕io.netty:netty-transport-classes-epoll

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

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; 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).
  • If upgrading is not immediately possible, configure idle timeouts on connections to limit the lifetime of stale channels.

References

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenio.netty:netty-transport-classes-epoll≥ 4.2.0.Final&&< 4.2.13.Final4.2.13.Final

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-transport-classes-epoll. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update io.netty:netty-transport-classes-epoll to 4.2.13.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rwm7-x88c-3g2p is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-rwm7-x88c-3g2p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-rwm7-x88c-3g2p. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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:*
O3 Security · Impact-Aware SCA

Is GHSA-rwm7-x88c-3g2p in your dependencies?

O3 detects GHSA-rwm7-x88c-3g2p across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works