CVE-2026-59999: OpenSSH Privilege Escalation Vulnerability

CVE-2026-59999 Overview

CVE-2026-59999 is a configuration enforcement flaw in OpenSSH sshd versions before 10.4. The DisableForwarding=yes directive was documented to take precedence over other forwarding-related options, including PermitTunnel=yes. In affected releases, sshd failed to honor this precedence, allowing tunnel device forwarding to remain active despite an administrator explicitly disabling all forwarding. Attackers who authenticate to a hardened server can establish layer-2 or layer-3 tunnels the administrator intended to block. The issue is tracked as [CWE-348] Use of Less Trusted Source and is addressed in OpenSSH 10.4p1.

Critical Impact
DisableForwarding=yes does not suppress PermitTunnel=yes, permitting network tunnels through servers configured to prohibit all forwarding.

Affected Products

OpenSSH sshd versions prior to 10.4
Server deployments relying on DisableForwarding=yes for hardening
OpenSSH-derived distributions shipping vulnerable builds

Discovery Timeline

2026-07-08 - CVE-2026-59999 published to NVD
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-59999

Vulnerability Analysis

OpenSSH exposes multiple forwarding primitives, including TCP forwarding, agent forwarding, X11 forwarding, StreamLocal forwarding, and tunnel device (tun) forwarding controlled by PermitTunnel. The DisableForwarding=yes directive is a hardening switch intended to override all of these. Administrators use it as a single authoritative setting to strip forwarding capabilities from a server role such as a jump host or SFTP-only endpoint.

In releases before 10.4, the enforcement path for DisableForwarding did not consult or override the PermitTunnel code path. When both directives were configured, PermitTunnel=yes remained effective. Authenticated users could then request a tun-based tunnel and pivot network traffic through the server. The vulnerability class is a configuration precedence failure ([CWE-348]) rather than a memory-safety bug.

Root Cause

The root cause is missing enforcement logic. The DisableForwarding handler did not gate the tunnel device request path in sshd. Because tunnel forwarding is a distinct feature from TCP or agent forwarding, its permission check relied solely on PermitTunnel, ignoring the global disable flag.

Attack Vector

Exploitation requires valid credentials on the target sshd instance and a server configuration that combines DisableForwarding=yes with PermitTunnel=yes. An authenticated client requests a tun device using ssh -w, and the server allocates the interface despite the disable directive. The attacker gains a layer-2 or layer-3 conduit that the administrator believed was blocked. Integrity impact is high because arbitrary network traffic can traverse a boundary meant to be closed. See the OpenSSH Release Notes 10.4p1 and the Openwall OSS-Security Mailing List Post for upstream discussion.

No verified proof-of-concept code is available for this issue. The
vulnerability is a configuration precedence bug in sshd; refer to the
OpenSSH 10.4p1 release notes for the corrected enforcement logic.

Detection Methods for CVE-2026-59999

Indicators of Compromise

Unexpected tun or tap interfaces created on hosts running sshd
sshd audit entries showing tunnel device allocation for authenticated sessions on servers configured with DisableForwarding=yes
Outbound routing or ARP activity originating from an SSH server role that should not forward traffic

Detection Strategies

Inventory OpenSSH server versions and flag any host running a release earlier than 10.4
Parse sshd_config across the fleet for the combination of DisableForwarding yes and PermitTunnel yes and correlate with the installed version
Alert on kernel events that create tun/tap devices attributable to sshd child processes

Monitoring Recommendations

Forward sshd and auditd logs to a centralized analytics tier for retention and correlation
Baseline expected network interfaces on SSH bastions and alert on new virtual interface creation
Track authentication events tied to sessions that subsequently allocate tunnel devices

How to Mitigate CVE-2026-59999

Immediate Actions Required

Upgrade sshd to OpenSSH 10.4p1 or later on all affected systems
Set PermitTunnel no explicitly in sshd_config until the upgrade is deployed
Audit accounts with shell access on hosts configured for DisableForwarding=yes and reduce membership where possible

Patch Information

OpenSSH addressed the precedence failure in the 10.4p1 release. Administrators should apply the upstream package or a distribution build that incorporates the fix. Details are documented in the OpenSSH Release Notes 10.4p1 and the Marc Info OpenSSH Discussion.

Workarounds

Set PermitTunnel no explicitly rather than relying on DisableForwarding=yes alone
Restrict tunnel device creation at the operating system level by removing CAP_NET_ADMIN from the sshd service where feasible
Enforce network egress controls that block unexpected layer-3 traffic originating from SSH server roles

bash

# /etc/ssh/sshd_config hardening for pre-10.4 deployments
DisableForwarding yes
PermitTunnel no
AllowTcpForwarding no
AllowStreamLocalForwarding no
AllowAgentForwarding no
X11Forwarding no

# Validate configuration and reload
sshd -t && systemctl reload sshd