{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/epoll/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["netty-transport-native-epoll ( \u003c 4.2.13.Final)"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","netty","epoll","resource-exhaustion"],"_cs_type":"advisory","_cs_vendors":["Netty"],"content_html":"\u003cp\u003eA denial-of-service vulnerability exists in Netty\u0026rsquo;s epoll transport for versions 4.2.x up to and including 4.2.12.Final. When \u003ccode\u003eALLOW_HALF_CLOSURE\u003c/code\u003e is enabled (or when using the HTTP codec), if a remote peer sends a FIN (half-close) followed by a RST, the server-side channel is not properly closed. This can lead to stale channels accumulating, exhausting file descriptors, memory, or connection count limits. In certain code paths, it can also trigger a 100% CPU busy-loop in the event loop thread, starving other connections. This vulnerability allows an unauthenticated remote attacker to cause a denial of service. The issue is resolved in version 4.2.13.Final.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA client establishes a TCP connection with a Netty-based server using the epoll transport.\u003c/li\u003e\n\u003cli\u003eThe server configures the connection with \u003ccode\u003eALLOW_HALF_CLOSURE\u003c/code\u003e enabled or uses the HTTP codec which can result in a half-closed state.\u003c/li\u003e\n\u003cli\u003eThe client sends a FIN packet to initiate a half-close of the TCP connection, signaling that it will no longer send data.\u003c/li\u003e\n\u003cli\u003eThe server acknowledges the FIN and marks the input side of the channel as shutdown.\u003c/li\u003e\n\u003cli\u003eThe client abruptly terminates the connection by sending a RST packet (e.g., by closing the socket with \u003ccode\u003eSO_LINGER=0\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eDue to a flaw in Netty\u0026rsquo;s epoll transport, the server fails to process the \u003ccode\u003eEPOLLERR\u003c/code\u003e or \u003ccode\u003eEPOLLHUP\u003c/code\u003e event triggered by the RST.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003echannelInactive\u003c/code\u003e event is never fired, leaving the channel in a stale state.\u003c/li\u003e\n\u003cli\u003eAn attacker repeats this process, accumulating stale channels and exhausting server resources, potentially leading to a CPU busy-loop and a denial-of-service condition.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability can lead to a denial-of-service condition. An unauthenticated remote attacker can exhaust server resources like file descriptors, memory, and connection limits, or trigger a CPU busy-loop. This can render the affected Netty-based service unavailable, impacting legitimate users. The number of potential victims depends on the scale of the deployment and the server\u0026rsquo;s resource capacity.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Netty version 4.2.13.Final or later to patch CVE-2026-42577 and resolve the vulnerability.\u003c/li\u003e\n\u003cli\u003eIf upgrading is not immediately feasible, configure idle timeouts on connections to limit the lifetime of stale channels, mitigating the resource exhaustion impact.\u003c/li\u003e\n\u003cli\u003eMonitor CPU utilization of Netty event loop threads. Investigate processes with high CPU usage for extended periods to identify potential exploitation of this vulnerability.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on new TCP connections from individual source IPs to reduce the effectiveness of connection exhaustion attacks.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-06T23:10:41Z","date_published":"2026-05-06T23:10:41Z","id":"/briefs/2024-01-netty-dos/","summary":"Netty's epoll transport fails to properly close TCP connections that receive a RST after a half-close, leading to resource exhaustion and potential CPU busy-loops, impacting service availability.","title":"Netty epoll Transport Denial of Service via RST on Half-Closed TCP Connection","url":"https://feed.craftedsignal.io/briefs/2024-01-netty-dos/"}],"language":"en","title":"CraftedSignal Threat Feed — Epoll","version":"https://jsonfeed.org/version/1.1"}