CVE-2026-45536: Netty Information Disclosure Vulnerability

CVE-2026-45536 Overview

CVE-2026-45536 is a file descriptor leak in Netty, the network application framework used to build protocol servers and clients in Java. The flaw resides in the native netty_unix_socket_recvFd function used by Unix domain socket channels. When a peer sends an SCM_RIGHTS ancillary message carrying two file descriptors, Netty installs both descriptors in the receiving process but only validates for a single descriptor. The branch that would consume the descriptor is skipped, and neither installed descriptor is closed. Each malformed message leaks two descriptors. The issue affects Netty versions prior to 4.1.135.Final and 4.2.15.Final.

Critical Impact
A local peer connected over a Unix domain socket can exhaust the receiving process's file descriptor table, leading to denial of service. The flaw is reachable only when the application opts into DomainSocketReadMode.FILE_DESCRIPTORS.

Affected Products

Netty versions prior to 4.1.135.Final
Netty versions prior to 4.2.15.Final
Applications using Epoll or KQueue DomainSocketChannel with DomainSocketReadMode.FILE_DESCRIPTORS

Discovery Timeline

2026-06-12 - CVE-2026-45536 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-45536

Vulnerability Analysis

The vulnerability is an Information Exposure issue tracked under [CWE-200], manifesting as a file descriptor resource leak. Netty's native receive routine netty_unix_socket_recvFd allocates a control message buffer sized for exactly one descriptor: char control[CMSG_SPACE(sizeof(int))], which is 24 bytes on 64-bit Linux. A peer can craft an SCM_RIGHTS control message containing two integers. That payload has cmsg_len = CMSG_LEN(8) = 24, which fits the buffer exactly. No MSG_CTRUNC flag is raised, so the kernel installs both descriptors into the receiving process before Netty validates the message.

Root Cause

The length check at line 972 compares cmsg->cmsg_len == CMSG_LEN(sizeof(int)), expecting the value 20 for a single descriptor. With two descriptors present the value is 24, so the equality check fails. Netty's code skips the branch that reads and tracks the descriptor. The descriptors remain open in the process, with no reference held by Java code to close them. The implementation also performs no MSG_CTRUNC handling, so truncated multi-descriptor messages also escape detection.

Attack Vector

Exploitation requires a local peer able to connect to the affected Unix domain socket and send SCM_RIGHTS ancillary data. The application must have opted into DomainSocketReadMode.FILE_DESCRIPTORS, which is not the default mode. The outer for(;;) loop calls recvmsg again, returns EAGAIN on non-blocking sockets, and exits the read loop cleanly, masking the leak. Repeated messages from a malicious peer accumulate descriptors until the process hits its RLIMIT_NOFILE ceiling, after which new connections, files, and sockets fail to open.

No public proof-of-concept or in-the-wild exploitation has been reported. See the GitHub Security Advisory GHSA-w573-9ffj-6ff9 for vendor details.

Detection Methods for CVE-2026-45536

Indicators of Compromise

Steadily increasing file descriptor counts in JVM processes hosting Netty Unix domain socket listeners.
Too many open files errors or EMFILE returns in application logs without correlating workload growth.
Unexpected entries in /proc/<pid>/fd/ referencing sockets or files not opened by application logic.

Detection Strategies

Inventory Java applications using netty-transport-native-epoll or netty-transport-native-kqueue and verify whether DomainSocketReadMode.FILE_DESCRIPTORS is configured.
Audit dependency manifests for Netty versions below 4.1.135.Final or 4.2.15.Final using software composition analysis tools.
Compare process file descriptor counts against historical baselines to flag monotonic growth indicative of a leak.

Monitoring Recommendations

Export /proc/<pid>/status or JMX OperatingSystemMXBean.getOpenFileDescriptorCount() metrics to your observability stack.
Alert on Unix domain socket peers sending unusually high volumes of ancillary control messages.
Track JVM restarts and EMFILE exceptions as secondary signals of resource exhaustion.

How to Mitigate CVE-2026-45536

Immediate Actions Required

Upgrade Netty to 4.1.135.Final or 4.2.15.Final across all build pipelines and runtime environments.
Audit application configuration for any use of DomainSocketReadMode.FILE_DESCRIPTORS and confirm it is required.
Restrict filesystem permissions on Unix domain socket paths to trusted local users only.

Patch Information

The Netty maintainers fixed this issue in Netty 4.1.135.Final and Netty 4.2.15.Final. Both releases correct the control buffer sizing and length validation logic in netty_unix_socket_recvFd so that multi-descriptor SCM_RIGHTS messages are handled safely and any installed descriptors are closed.

Workarounds

Switch the affected channel to DomainSocketReadMode.BYTES, which does not exercise the vulnerable code path.
Lower the process RLIMIT_NOFILE ceiling cautiously to contain blast radius while patching is scheduled.
Use OS-level access controls such as SELinux or AppArmor to restrict which peers can connect to the Netty socket.

bash

# Configuration example: pin Netty to a patched version in Maven
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-all</artifactId>
#   <version>4.1.135.Final</version>
# </dependency>
mvn dependency:tree | grep -E 'netty.*:(jar|bundle):'