In Netty, the Unix‑socket receive routine prepares a 24‑byte control buffer for passing file descriptors. When a peer sends a SCM_RIGHTS control message with two descriptors, the kernel correctly installs both descriptors. Netty then checks the message length for a single‑descriptor packet; this check fails and the code that would extract and close the descriptors is skipped. Consequently both descriptors remain open on the receiving side, leaking two file descriptors per message. The flaw represents an improper validation of message length (CWE‑167), a failure to release resources properly (CWE‑772), and an inadvertent information disclosure (CWE‑200). Though no code execution or privilege escalation is possible, repeated exploitation could lead to file‑descriptor exhaustion and availability problems.

The vulnerability affects Netty releases 4.1.x through the last unpatched build prior to 4.1.135.Final and 4.2.x through the last unpatched build before 4.2.15.Final. It is reachable only when an application uses an Epoll or KQueue DomainSocketChannel and enables the non‑default DomainSocketReadMode.FILE_DESCRIPTORS mode, allowing a peer to send Unix domain socket messages that include file descriptors.

The CVSS score of 4.0 indicates low severity. The EPSS score of <1% and the absence from the CISA KEV catalog suggest that exploitation is currently rare. The likely attack vector is a local or far‑me setup where a malicious peer can connect to the application’s Unix domain socket and transmit a crafted SCM_RIGHTS message carrying two descriptors. Once processed, the application leaks the descriptors; repeated exploitation could exhaust the process’s descriptor table, causing denial of service. No remote code execution or privilege escalation is enabled through this flaw, but the risk is notable for long‑running services that do not monitor or limit file‑descriptor usage.