Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

Maven package

io.netty:netty-transport-classes-epoll

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5MavenPublished

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

    CVE-2026-42577 · GHSA-rwm7-x88c-3g2p

    Affected
    • Maven io.netty:netty-transport-classes-epoll >= 4.2.0.Final, < 4.2.13.Final
    Fixed in
    4.2.13.Final· Vendor fix available
    Issue
    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 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:…

    Recommended action: Upgrade to 4.2.13.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →