CVE-2026-42792: 
CBL Mariner Analisi e mitigazione delle vulnerabilità

CVE-2026-42792 is a Denial-of-Service vulnerability in Erlang OTP's Erlang Port Mapper Daemon (epmd) that allows an unauthenticated remote attacker to permanently terminate the daemon via connection slot exhaustion. Disclosed on July 27, 2026, it affects Erlang/OTP versions from OTP 17.0 before OTP 29.0.4, 28.5.0.4, and 27.3.4.15, as well as erts versions from 6.0 onward. The vulnerability has a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is improper handling of exceptional conditions (CWE-755) combined with allocation of resources without limits or throttling (CWE-770) in the do_accept function within erts/epmd/src/epmd_srv.c. When accept(2) returns EMFILE (per-process file descriptor limit reached) or ENFILE (system-wide file descriptor limit reached), the function incorrectly calls epmd_cleanup_exit() rather than treating these as recoverable, transient errors. An attacker exploits this by opening many TCP connections to epmd (TCP port 4369) and periodically sending a single byte per connection to reset the idle timeout, preventing disconnection; once file descriptors are exhausted, the next accept(2) call returns EMFILE and kills the daemon. Because epmd implements no per-source-IP connection cap, the entire attack is feasible from a single host. The fix (commit 865d203) adds EMFILE and ENFILE to the list of recoverable accept(2) errors, returning EPMD_FALSE instead of calling epmd_cleanup_exit() (GitHub Advisory, Patch Commit).

Successful exploitation results in permanent termination of the epmd daemon, causing a Denial of Service with high availability impact and no confidentiality or integrity impact. On Debian/Ubuntu systems, the impact is amplified: the systemd unit inherits a low file descriptor soft limit, and repeated daemon deaths trigger systemd's start-rate-limit, permanently failing both epmd.service and epmd.socket and requiring manual operator intervention to restore service. Since epmd is the name resolution service for Erlang distributed nodes, its unavailability prevents Erlang/OTP nodes from discovering and connecting to each other, disrupting any distributed Erlang application (e.g., RabbitMQ, Elixir-based services) running on the affected host (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and the EPSS score is approximately 0.387%, indicating a low probability of exploitation in the near term. The attack requires no authentication, no user interaction, and is executable from a single source IP, but does require the attacker to be able to reach TCP port 4369 (epmd), which should not be exposed on untrusted networks. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable (GitHub Advisory).

1. Reconnaissance: Identify hosts running Erlang/OTP with epmd exposed on TCP port 4369 using network scanners such as Nmap (nmap -p 4369 <target>) or Shodan queries for the epmd service banner.
2. Establish many persistent TCP connections: Open a large number of TCP connections to the target's port 4369 (up to or near the epmd process's file descriptor limit, typically a few hundred to a few thousand depending on system configuration).
3. Reset idle timeouts: For each open connection, periodically send a single byte of data to reset epmd's idle timeout mechanism, preventing the daemon from closing idle connections and freeing file descriptors.
4. Trigger EMFILE condition: Once file descriptors are exhausted, any new incoming connection attempt causes accept(2) to return EMFILE. The vulnerable do_accept function then calls epmd_cleanup_exit(), terminating the daemon.
5. Amplify on Debian/Ubuntu: Repeat the attack rapidly to trigger systemd's start-rate-limit, causing both epmd.service and epmd.socket to enter a permanently failed state, requiring manual systemctl reset-failed and restart by an operator (GitHub Advisory, Red Hat Bugzilla).

• Network: Unusually high number of concurrent TCP connections from one or few source IPs to port 4369 (epmd); connections that remain open without completing a full epmd protocol exchange.
• Logs: Systemd journal entries showing repeated epmd.service start failures (e.g., epmd.service: Start request repeated too quickly); epmd.service and epmd.socket entering failed state in systemctl status output.
• Process: Sudden absence of the epmd process on a host that should be running Erlang/OTP nodes; Erlang node connection errors in application logs referencing inability to contact epmd.
• System: File descriptor exhaustion events in kernel logs (dmesg or /var/log/syslog) such as socket: Too many open files; systemctl is-failed epmd.service returning failed (GitHub Advisory).

Upgrade Erlang/OTP to patched versions: OTP 29.0.4, OTP 28.5.0.4, or OTP 27.3.4.15 (or later), which fix the do_accept function to treat EMFILE/ENFILE as recoverable errors (GitHub Advisory, Patch Commit). For systems that cannot be patched immediately, apply the following workarounds:

• Restrict epmd to loopback: In /etc/systemd/system/epmd.socket.d/override.conf, clear the default wildcard binding with an empty ListenStream= and add ListenStream=127.0.0.1:4369 and ListenStream=[::1]:4369.
• Raise file descriptor limits: Add LimitNOFILE=65536 to /etc/systemd/system/epmd.service.d/override.conf.
• Enable automatic restart: Add Restart=always with a suitable RestartSec in the epmd service override.
• Firewall: Restrict TCP port 4369 to trusted hosts only using firewall rules (GitHub Advisory).

The vulnerability was responsibly disclosed by researcher Ryan Moore (GitHub handle: renmizo) to the Erlang/OTP project, which published the advisory on July 27, 2026 (GitHub Advisory). Red Hat opened a high-severity bug tracking entry for the issue in their Bugzilla system (Red Hat Bugzilla). No significant broader media coverage or notable social media discussion has been identified at this time.