CVE-2026-45536

What it actually does

This flaw causes a file descriptor leak in Netty's native Unix domain socket file-descriptor receiving path. When an application uses Epoll/KQueue DomainSocketChannel with DomainSocketReadMode.FILE_DESCRIPTORS enabled, a local peer can send an SCM_RIGHTS control message containing two file descriptors. The kernel installs both descriptors into the receiving Java process, but Netty rejects the control message length as unexpected and fails to close the installed descriptors. Repeating this operation consumes the target process's file descriptor limit, eventually causing failures to accept connections, open files, create sockets, or perform other I/O. The practical impact is availability degradation or denial of service; the issue does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Affected services can be made unstable or unavailable if an attacker can communicate with a vulnerable Unix domain socket configured to receive file descriptors. Because Netty is widely used as an embedded networking framework, the vulnerable code may be present indirectly through applications, platforms, gateways, brokers, or internal services that depend on Netty native transports. Risk is lower where Unix domain sockets are not exposed to untrusted local users, containers, plugins, or sidecars, and where FILE_DESCRIPTORS mode is not enabled. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has very low EPSS, but it should still be remediated in systems where local multi-tenant boundaries or container-to-host/socket boundaries are security-relevant.

How an attack unfolds

An attacker first needs local or adjacent access to a Unix domain socket served by an application using vulnerable Netty native transport code and configured with DomainSocketReadMode.FILE_DESCRIPTORS. The attacker connects as a peer and repeatedly sends SCM_RIGHTS ancillary data containing two file descriptors in a single message. Linux accepts the control message and installs both file descriptors into the receiving process. Netty then checks for the length expected for a single descriptor, treats the message as not matching the expected format, skips the normal descriptor handling path, and does not close the descriptors that the kernel already installed. The receive loop exits normally after EAGAIN, leaving the leaked descriptors open. By repeating the send operation, the attacker consumes the target process's file descriptor table until the process reaches its open-file limit, producing errors such as EMFILE or 'Too many open files' and causing service disruption.

How to fix it

Upgrade Netty to a fixed release: 4.1.135.Final or later for the 4.1.x line, or 4.2.15.Final or later for the 4.2.x line. Update all Netty modules consistently, especially native transport artifacts such as netty-transport-native-epoll, netty-transport-native-kqueue, netty-transport-native-unix-common, and any bundled or shaded Netty copies. If immediate upgrade is not possible, disable use of DomainSocketReadMode.FILE_DESCRIPTORS where not strictly required, avoid accepting file descriptors from untrusted peers, restrict Unix domain socket filesystem permissions, isolate the process from untrusted local users or containers, and set conservative service restart/health-check behavior. Resource limits such as ulimit nofile can reduce blast radius but do not fix the leak; they should be treated as containment only.

How to confirm the fix worked

Confirm the resolved dependency tree contains Netty 4.1.135.Final or later, or 4.2.15.Final or later, across all Netty artifacts and that no older shaded Netty copy remains inside application bundles. Review code and configuration for use of EpollDomainSocketChannel, KQueueDomainSocketChannel, DomainSocketChannel, and DomainSocketReadMode.FILE_DESCRIPTORS. Verify Unix domain sockets that receive file descriptors are not accessible by untrusted local users or containers. In a controlled test environment, exercise legitimate file-descriptor passing and monitor the Java process's open descriptor count; after patching, malformed or multi-descriptor SCM_RIGHTS messages should not cause a steadily increasing descriptor count. Operationally, validate that file descriptor usage remains stable under repeated local socket interactions and that no 'Too many open files' errors occur during stress testing.

Typical attack path

1. Identify an application using Netty native Unix domain socket support, such as epoll or kqueue domain socket channels.
2. Confirm the application has opted into DomainSocketReadMode.FILE_DESCRIPTORS, which is not the default mode.
3. Obtain local peer access to the Unix domain socket, for example through a local account, container, sidecar, plugin, or misconfigured socket permissions.
4. Open a connection to the Unix domain socket.
5. Send repeated SCM_RIGHTS control messages where each message carries two file descriptors.
6. Cause the kernel to install the descriptors into the receiving Java process while Netty fails to consume or close them.
7. Continue until the Java process reaches its file descriptor limit.
8. Trigger operational failure as the service can no longer accept connections, open files, create sockets, or perform required I/O.

How to detect it

To determine whether this issue may already have been exploited, focus on evidence of abnormal file descriptor growth in Java processes that use Netty Unix domain sockets. Review application logs, systemd journals, container logs, kernel/audit logs, and observability metrics for sudden increases in open file descriptors followed by EMFILE or 'Too many open files' errors. Correlate these events with local Unix domain socket connection activity, especially from unexpected users, containers, sidecars, or helper processes. On Linux, inspect historical process metrics if available, auditd records for connect/sendmsg activity to sensitive Unix sockets, container runtime logs, and endpoint telemetry showing repeated local socket interactions. In live response, compare /proc/<pid>/fd counts over time and examine whether many descriptors are held by the Java process without corresponding application-level activity. There may be no unique network IOC because exploitation occurs over local Unix domain sockets and the malicious SCM_RIGHTS payload is typically not logged by default.

• Too many open files
• EMFILE
• java.io.IOException: Too many open files
• java.net.SocketException: Too many open files
• io.netty.channel.unix.Errors$NativeIoException
• recvFd
• DomainSocketReadMode.FILE_DESCRIPTORS
• SCM_RIGHTS
• /proc/*/fd

What your security team should do

• Inventory applications and third-party products that embed Netty, prioritizing Linux or macOS services using native transports and Unix domain sockets.
• Upgrade all affected Netty dependencies to 4.1.135.Final or later, or 4.2.15.Final or later, ensuring version alignment across Netty modules.
• Search code repositories and deployed configuration for DomainSocketReadMode.FILE_DESCRIPTORS and Unix domain socket usage to determine practical exploitability.
• Restrict Unix domain socket permissions so only trusted service accounts can connect, especially in multi-user hosts, Kubernetes nodes, container platforms, and plugin-based systems.
• Monitor Java services for unexplained file descriptor growth, EMFILE errors, and availability degradation until patching is complete.
• Check for shaded or vendor-bundled Netty copies in executable JARs, application servers, agents, and appliances rather than relying only on top-level package manifests.
• If patching must be delayed, disable file-descriptor passing features or isolate the vulnerable socket from untrusted local peers.