CVE-2026-42792

Executive Summary

CVE-2026-42792 is a denial-of-service vulnerability in the Erlang Port Mapper Daemon (epmd), the service responsible for resolving node names to port numbers in distributed Erlang systems. An unauthenticated remote attacker can permanently terminate epmd, effectively killing distributed Erlang applications (e.g., RabbitMQ, CouchDB, Riak) that depend on the node registry.

The vulnerability stems from improper exception handling in the do_accept() function of erts/epmd/src/epmd_srv.c. When the daemon's file descriptor limit is reached, accept(2) returns EMFILE/ENFILE, and instead of treating this as a temporary, recoverable resource exhaustion condition, the code calls epmd_cleanup_exit() — terminating the entire daemon process. The impact is amplified on systemd-managed Debian/Ubuntu systems where repeated rapid restarts trigger systemd's start-rate-limiting, leaving epmd.service permanently in a failed state. The attacker neither requires authentication nor must be on a trusted network, making this a remotely exploitable condition whenever epmd is exposed beyond loopback.

Technical Analysis

The vulnerability resides in erts/epmd/src/epmd_srv.c, within the do_accept() function which handles the main server accept loop. The flawed code path is as follows:

static void do_accept(int fd) {
    int s;
    socklen_t addrlen = sizeof(struct sockaddr_storage);
    struct sockaddr_storage addr;

    s = accept(fd, (struct sockaddr *) &addr, &addrlen);
    if (s < 0) {
        switch (errno) {
        case EMFILE:        /* per-process fd limit reached */
        case ENFILE:        /* system-wide fd limit reached */
            /* FLAW: treats resource exhaustion as fatal */
            epmd_cleanup_exit(1);
            break;
        case EINTR:
            /* retry — handled correctly */
            break;
        /* ... other errno values handled ... */
        }
    }
    /* ... spawn handler thread for accepted connection ... */
}

The critical logic error is the inclusion of EMFILE and ENFILE in the fatal-exit branch. These errno values indicate temporary resource exhaustion — the kernel refuses to allocate a new file descriptor — and are recoverable once existing connections close or the fd limit is raised. Correct handling would be to sleep briefly (e.g., usleep() or poll() with a timeout) and retry the accept, or to close idle connections. Instead, the code calls epmd_cleanup_exit(), which:

1. Closes the listening socket.
2. Terminates all active connection-handling threads.
3. Calls exit(1) — killing the daemon entirely.

Attack surface analysis:

• Network exposure: epmd listens on TCP port 4369. By default, it binds to all interfaces (0.0.0.0), not just loopback, meaning any host that can reach the target on port 4369 is a potential attacker.
• Connection handling: The daemon spawns one thread per accepted connection. There is no per-source-IP connection cap, no maximum connections setting, and no authentication required before a connection consumes resources.
• Idle timeout bypass: epmd has an idle timeout that closes connections after a period of inactivity. The attacker defeats this by sending a single byte (any byte) at intervals shorter than the timeout, which resets the timer and keeps the connection alive indefinitely.
• Path to EMFILE: The attacker opens the connection slot limit. Since epmd is a 32-bit or 64-bit process, and NPROC / RLIMIT_NOFILE on the daemon is typically 1024 (Soft limit on Debian/Ubuntu systemd units inherits LimitNOFILE=1024), an attacker needs to open fewer than ~1024 simultaneous connections on a default Debian/Ubuntu installation. On systems with higher limits (e.g., LimitNOFILE=infinity), the attacker only needs to exhaust the system-wide limit, which can be reached by crowding out all available FDs across all processes, though the per-process exhaustion is the primary vector.
• systemd amplification: When epmd exits, systemd attempts to restart it (if Restart=on-failure is set). The default StartLimitBurst (5 within 10 seconds) is quickly exceeded because each restart attempt results in another immediate crash if connections are still held. systemd then marks the unit as failed and stops attempting restarts, requiring systemctl reset-failed and manual intervention to recover. Additionally, if epmd.socket is configured with Accept=yes (socket activation), it too enters a failed state, breaking the entire socket activation chain.

Exploitation Scenarios

The following step-by-step exploit chain describes how an attacker leverages CVE-2026-42792:

Step 1: Reconnaissance

• The attacker scans for hosts exposed on TCP port 4369 using Shodan, Censys, or direct SYN scans (e.g., nmap -p 4369 --open -sV <target>).
• For each responding host, the attacker identifies the epmd service by sending a handshake. The Erlang distribution protocol requires a "name" request (magic cookie: EPMD / @erl epmd). A simple probe: echo -n -e '\x00\x01\x6e' | nc -v <target> 4369 returns a response that includes the Erlang node name and port, confirming the service is epmd.
• The attacker checks the OTP version by attempting to register a random node name and observing protocol differences, or by fingerprinting via error messages. Versions 17.0 through 29.0.3 are vulnerable (except 27.3.4.15+, 28.5.0.4+, 29.0.4+).

Step 2: Connection Slot Exhaustion

• The attacker opens a large number of TCP connections to the target's port 4369. A simple script using Python's socket library or a tool like pwntools can open connections in a loop.
• The attacker must defeat the idle timeout. epmd's EPMD_KEEP_ALIVE timeout defaults to 60 seconds (configurable). The attacker sends a single byte (e.g., \x00) every 30 seconds on each connection to keep it alive. Practically, the attacker can maintain ~1024 connections (the typical soft fd limit) with a small script.
• The attacker monitors the target's behavior. When the number of connections reaches the file descriptor limit, the next accept(2) call in the daemon will return EMFILE.

Step 3: Triggering the Fatal Error

• The attacker opens one additional connection. Since the listening socket itself consumes one fd, and each active connection consumes one fd, when the process hits RLIMIT_NOFILE, the accept(2) call fails with EMFILE.
• The vulnerable code path executes epmd_cleanup_exit(1). The daemon closes all sockets, shuts down all handler threads, and exits with status 1.
• If the attacker has already freed the connections or keeps them open, they receive ECONNRESET (connection reset) or the connections are abruptly closed.

Step 4: Permanent DoS via systemd Rate-Limiting

• On a Debian/Ubuntu system with the default epmd.service unit, systemd restarts the daemon automatically (default Restart=on-failure).
• The attacker reconnects immediately, exhausting the fd limit again, causing another crash. Systemd counts these restarts. After 5 crashes within 10 seconds (default StartLimitIntervalSec=10, StartLimitBurst=5), systemd transitions the unit to failed state and stops restarting it.
• The attacker stops connecting. However, epmd remains down. Any new legitimate Erlang node attempting to register will fail with an error like "unable to contact epmd on host ...". If epmd.socket is configured with socket activation, it is also marked failed; even if epmd were manually started, the socket unit prevents binding to port 4369.

Step 5: Post-Exploitation Impact

• All distributed Erlang nodes on the host become unable to register new node names. Existing node-to-node communication that relies on new connections (e.g., RabbitMQ cluster reconnects, CouchDB replication) fails.
• If the system has clustered Erlang services (RabbitMQ, Riak, CouchDB), the cluster is effectively partitioned, causing failover circuits, message queue backlog, and potential data inconsistency if quorum is lost.
• The operator must manually recover: systemctl reset-failed epmd and systemctl start epmd (or restart the affected Erlang services). This creates an availability window of several minutes, which for financial or critical infrastructure services constitutes a significant outage.

Impact Assessment

CVSS scoring: While the NVD entry lists no CVSS vector, the severity can be reasonably assessed using CVSS 3.1 as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, yielding a base score of 7.5 (High). The vector reflects: network-accessible (AV:N), low attack complexity (AC:L — no special conditions, just repeated connection openings), no privileges required (PR:N), no user interaction (UI:N), unchanged scope (S:U), no confidentiality or integrity impact (C:N / I:N), and high availability impact (A:H).

Criticality of exposed services: The real-world impact is proportional to the criticality of Erlang services listening on the host. For example:

• RabbitMQ — A widely-deployed message broker in financial services, e-commerce, and IoT backends. A permanent epmd failure breaks cluster membership and causes new connections to fail, leading to cascading service degradation.
• CouchDB / CouchBase — Distributed document databases sharing the Erlang VM. Cluster replication halts.
• ejabberd / MongooseIM — Chat servers lose federation and clustered presence updates.
• Riak / Riak CS — Distributed key-value stores lose cluster-awareness.

Blast radius: Any unauthenticated remote attacker can trigger this. Exploitation requires only ~1024 concurrent connections per target instance, which is trivially achievable from a single host. No packet spoofing, sophisticated payloads, or chaining of other vulnerabilities is needed.

Known exploitation: As of this writing, CISA KEV does not list CVE-2026-42792, EPSS score is low (0.00387), and no public PoC exists. However, the vulnerability is trivially exploitable, and the required technique is well-known (fd exhaustion over TCP). Attackers frequently weaponize such flaws within days of public disclosure. The absence of a dated discovery before the CVE's public release means this is an emerging threat.

Detection Guidance

Sigma Rule

title: CVE-2026-42792 - Erlang epmd EMFILE/ENFILE Denial of Service
status: experimental
description: Detects crashes of epmd possibly caused by file descriptor exhaustion, leading to permanent epmd service failure.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-42792
tags:
    - attack.t1190
    - cve.2026.42792
    - availability
author: ValtersIt Threat Intelligence Team
date: 2026/03/18
logsource:
    category: process_creation
    product: linux
detection:
    selection_epmd_exit:
        Image|endswith: '/epmd'
        CommandLine|contains: 'epmd'
    selection_systemd_kill:
        SystemdStatus|contains: 'FAILED'
    condition: selection_epmd_exit or selection_systemd_kill
falsepositives:
    - Legitimate epmd crash due to system resource limits
level: high

YARA Rule

rule CVE_2026_42792_Epmd_DoS_Ertlog {
    meta:
        author = "ValtersIt Threat Intelligence"
        description = "Detect epmd crash log entries indicating EMFILE/ENFILE termination"
        cve = "CVE-2026-42792"
        date = "2026-03-18"
    strings:
        $errno_emfile = "accept: emfile" ascii nocase
        $errno_enfile = "accept: enfile" ascii nocase
        $cleanup_exit = "epmd_cleanup_exit" ascii nocase
        $fd_exhausted = "file descriptor table overflow" ascii nocase
        $erl_crash = "erl_crash.dump" ascii nocase
    condition:
        any of ($errno_*) or ($cleanup_exit or $fd_exhausted)
}

Suricata IDS Rule

alert tcp any any -> any 4369 (msg:"CVE-2026-42792 - Erlang epmd connection flood / FD exhaustion"; flow:to_server; byte_test:1,>=,0,4; content:"|00 01 6e|"; depth:10; threshold:type limit, track by_src, seconds 60, count 500; classtype:attempted-dos; sid:10042792; rev:1; metadata:cve CVE-2026-42792;)

Elastic Detection

// Detect multiple rapid crashes of epmd process
process where event.type == "end" and process.name == "epmd"
| count by host.name limit 5 over 10s
| where count > 4

Splunk SPL Query

index=_internal source="/var/log/syslog" OR source="/var/log/daemon.log"
| rex "systemd\[1\]: epmd\.service: (Failed|Main process exited)"
| rex "epmd:.*(EMFILE|ENFILE|accept|cleanup_exit)"
| eval outcome = case(
    match(_raw, "epmd\.service: Failed"), "systemd_failed",
    match(_raw, "EMFILE|ENFILE"), "fd_exhaustion",
    match(_raw, "Main process exited"), "process_exit"
)
| stats count by outcome, host, _time
| search outcome IN ("fd_exhaustion", "systemd_failed")
| eval alert = if(outcome == "systemd_failed" AND count > 3, "CRITICAL", "WARN")

Wazuh OSSEC Rule

<group name="erlang,">
    <rule id="100427" level="12">
        <if_sid>530</if_sid>
        <match>epmd_cleanup_exit|accept: emfile|accept: enfile|File descriptor table exhausted</match>
        <description>CVE-2026-42792: Erlang epmd terminated due to EMFILE/ENFILE (possible DoS attack)</description>
        <group>availability,epmd,</group>
        <cve-id>CVE-2026-42792</cve-id>
        <options>no_full_log</options>
    </rule>
    <rule id="100428" level="10">
        <if_sid>530</if_sid>
        <regex>epmd\.service: .* (failed|entered failed)</regex>
        <description>CVE-2026-42792: epmd.service entered failed state (systemd rate limit exceeded)</description>
        <group>availability,epmd,systemd,</group>
        <cve-id>CVE-2026-42792</cve-id>
    </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed)

1) Immediate mitigations:

• Restrict network exposure: Add a systemd socket override to bind epmd to loopback only:

  /etc/systemd/system/epmd.socket.d/override.conf
  [Socket]
  ListenStream=
  ListenStream=127.0.0.1:4369
  ListenStream=[::1]:4369
  

  Then run systemctl daemon-reload && systemctl restart epmd.socket.

• Firewall: Add a strict firewall rule (iptables/nftables/cloud SG) allowing TCP 4369 only from trusted IP ranges, preferably only the internal node mesh IPs. In most deployments, epmd does not need to be reachable from outside the cluster.

• Raise fd limits and configure automatic restart:

  /etc/systemd/system/epmd.service.d/override.conf
  [Service]
  LimitNOFILE=65536
  Restart=always
  RestartSec=5
  

  Then systemctl daemon-reload && systemctl restart epmd.

2) Patch/Upgrade steps:

• Upgrade to a fixed OTP version: OTP 27.3.4.15, 28.5.0.4, or 29.0.4. Consult your OS package manager (Debian/Ubuntu: apt upgrade erlang; Homebrew: brew upgrade erlang; Erlang Solutions: manual).
• If your Erlang runtime is a bundled dependency (e.g., inside RabbitMQ's embedded Erlang), upgrade the parent application to the version that bundles a patched OTP (check vendor-specific advisories for RabbitMQ 4.x/3.x).
• After upgrading, verify the fix: epmd -version and confirm the version string matches the patched release. Independently confirm the patch exists by testing with a local connection flood that would previously crash epmd.

3) Long-term hardening:

• Run epmd under an isolated user with a minimal environment. Prefer systemd socket activation with Accept=no and let epmd handle connections itself.
• Monitor epmd for abnormal connection counts using any of the detection rules provided above. Set alerts on:
  • More than 500 simultaneous TCP connections to port 4369 from a single source IP.
  • Sudden epmd process exits.
  • EMFILE/ENFILE messages in system logs.
• Enable kernel-level connection rate limiting: e.g., iptables -A INPUT -p tcp --dport 4369 -m connlimit --connlimit-above 100 -j REJECT.
• Consider switching to TLS with mutual authentication for Erlang distribution (-proto_dist inet_tls), which forces both encrypted and authenticated connections before any resource-intense handler runs (though epmd itself does not support TLS, so firewalling it remains essential).
• Keep an inventory of all hosts running epmd and apply the loopback-restriction override by default in provisioning scripts (Ansible/Puppet/Terraform).

References

1. NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-42792
2. OSV advisory: https://osv.dev/vulnerability/CVE-2026-42792
3. Official Erlang/OTP security announce mailing list: https://erlang.org/security.html (referenced for patch versions)
4. Erlang Port Mapper Daemon source — affected code: https://github.com/erlang/otp/blob/master/erts/epmd/src/epmd_srv.c (observe the do_accept function)
5. CISA Known Exploited Vulnerabilities catalog — listed: NO as of this writing.

Threat actor activity: No known threat actor campaigns referencing CVE-2026-42792 have been publicly reported as of this writing. The EPSS percentile (31.5%) suggests a moderate likelihood of exploitation in the wild once the vulnerability becomes widely known. Organizations should prioritize patching within 30 days for exposed deployments.