CVE-2025-46807: sslh DoS Vulnerability via Resource Exhaustion

CVE-2025-46807 Overview

CVE-2025-46807 is a resource exhaustion vulnerability in sslh, the protocol-demultiplexing proxy that routes traffic from a single port to multiple backend services such as HTTPS, SSH, and OpenVPN. The flaw allows unauthenticated remote attackers to exhaust the file descriptors available to the sslh process, denying service to legitimate users. The vulnerability is classified under CWE-770: Allocation of Resources Without Limits or Throttling. It affects all versions of sslh prior to 2.2.4.

Critical Impact

Remote, unauthenticated attackers can trivially exhaust file descriptors in sslh, blocking SSH, HTTPS, and other multiplexed services from reaching legitimate users.

Affected Products

• sslh versions before 2.2.4
• Linux distributions packaging vulnerable sslh builds (tracked via SUSE Bugzilla CVE-2025-46807)
• Any environment using sslh as a front-end multiplexer for SSH, HTTPS, OpenVPN, or similar protocols

Discovery Timeline

• 2025-06-02 - CVE-2025-46807 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2025-46807

Vulnerability Analysis

sslh listens on a shared port and inspects incoming connections to forward them to the correct backend service based on protocol fingerprints. To perform this inspection, it accepts the TCP connection and holds the socket open while it waits for client data. The vulnerability stems from the absence of any rate limit or cap on the number of concurrent half-open or pending connections that sslh will track. An attacker who opens connections faster than sslh can process them consumes one file descriptor per connection. Once the process reaches the operating system file descriptor limit, accept() calls begin failing and new legitimate clients cannot connect. The EPSS score is 0.385% with a percentile of 59.785, reflecting moderate predicted exploitation activity.

Root Cause

The root cause is missing throttling logic in the connection-handling path of sslh. The daemon allocates a socket descriptor for every inbound TCP connection but does not enforce a per-source or global concurrency ceiling. There is also no timeout aggressive enough to reclaim descriptors held by clients that never send protocol data. This design lets a single host or a small set of hosts consume the entire descriptor pool.

Attack Vector

Exploitation requires only network reachability to the sslh listening port. The attacker opens TCP connections to the proxy and either holds them idle or sends no protocol-identifying bytes. Each lingering connection occupies a file descriptor in the sslh process. Because no authentication is required and the connections do not need to complete a higher-layer handshake, the attack is inexpensive and scriptable with standard tooling such as nc or custom socket loops. The vulnerability does not impact confidentiality or integrity, only availability.

No verified proof-of-concept code is published. The technical mechanism is documented in the GitHub release notes for sslh v2.2.4, which introduces connection limits to address the issue.

Detection Methods for CVE-2025-46807

Indicators of Compromise

• Sudden spike in concurrent TCP connections to the port hosting sslh (commonly 443 or 22) without matching application-layer traffic
• sslh log entries reporting accept: Too many open files or EMFILE errors
• Legitimate SSH or HTTPS clients receiving connection refusals or timeouts while the host remains otherwise reachable
• Large numbers of ESTABLISHED sockets from a small set of source IPs visible in ss -tn or netstat output

Detection Strategies

• Monitor the sslh process file descriptor count via /proc/<pid>/fd and alert when it approaches the configured ulimit -n ceiling
• Correlate connection counts per source IP against historical baselines to flag high-fanout clients
• Parse sslh stderr and syslog output for repeated accept failures or descriptor allocation errors

Monitoring Recommendations

• Export socket statistics from front-end hosts to your SIEM or data lake for trend analysis and threshold alerting
• Track service availability of downstream protocols (SSH, HTTPS) end-to-end so degradation triggered by upstream sslh exhaustion is detected quickly
• Enable network flow logging at the perimeter to identify source addresses generating abnormal connection volumes to multiplexed ports

How to Mitigate CVE-2025-46807

Immediate Actions Required

• Upgrade sslh to version 2.2.4 or later on all hosts running the proxy
• Identify any distribution-packaged sslh builds and apply vendor updates referenced in advisories such as SUSE Bugzilla CVE-2025-46807
• Restrict inbound access to the sslh listening port with firewall rules where feasible, particularly from untrusted networks

Patch Information

The upstream fix is available in the sslh v2.2.4 release, which adds connection limiting to prevent file descriptor exhaustion. Operators should rebuild or repackage sslh from this release or apply the corresponding distribution update.

Workarounds

• Raise the nofileulimit for the sslh service unit to increase the attack effort required, while recognizing this is not a fix
• Place a connection-rate-limiting reverse proxy or stateful firewall in front of sslh to cap concurrent sessions per source IP
• Use iptables or nftablesconnlimit modules to throttle inbound TCP connections to the multiplexed port

# Example: limit concurrent connections per source IP to the sslh port using iptables
iptables -A INPUT -p tcp --dport 443 --syn \
  -m connlimit --connlimit-above 20 --connlimit-mask 32 \
  -j REJECT --reject-with tcp-reset

# Example: raise file descriptor limit for the sslh systemd service (mitigation only)
mkdir -p /etc/systemd/system/sslh.service.d
cat >/etc/systemd/system/sslh.service.d/limits.conf <<'EOF'
[Service]
LimitNOFILE=65535
EOF
systemctl daemon-reload
systemctl restart sslh