CVE-2026-59999

What it actually does

This flaw is an authorization-control bypass in OpenSSH sshd versions before 10.4. When sshd is configured with both DisableForwarding=yes and PermitTunnel=yes, the intended behavior is that DisableForwarding=yes should override and disable all forwarding-related capabilities. In affected versions, PermitTunnel=yes can still allow SSH tunnel device forwarding despite the broader DisableForwarding restriction. Successful exploitation generally requires network access to sshd and the ability to establish an SSH session for an account or context governed by the vulnerable configuration. The main technical consequence is unauthorized creation of SSH-based network tunnels, which can bypass network segmentation, access controls, monitoring assumptions, and administrative policy.

Why it matters to the business

An attacker or unauthorized user who can log in to an affected SSH service may be able to create network tunnels even when administrators believed all forwarding was disabled. This can enable covert pivoting into internal networks, bypass firewall or bastion restrictions, obscure traffic origin, and undermine compliance controls around restricted administrative access. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or public exploit maturity indicated, but OpenSSH is widely deployed and configuration-dependent exposure should still be reviewed promptly, especially on bastion hosts, jump servers, internet-facing SSH services, and systems used to enforce network access boundaries.

How an attack unfolds

An attacker first identifies an SSH service running an affected OpenSSH version before 10.4. The attacker then needs a way to authenticate to the service, such as valid credentials, a compromised key, or access to an account intentionally permitted to use SSH. If the server configuration or a Match block applies both DisableForwarding=yes and PermitTunnel=yes, the attacker can request SSH tunnel forwarding even though administrators expected DisableForwarding to block it. Once the tunnel is established, traffic can be routed through the SSH connection to reach networks or services that are otherwise not directly accessible from the attacker’s location. The tunnel may then be used for reconnaissance, lateral movement, data staging, access to internal administrative interfaces, or evasion of network monitoring controls that assume forwarding is disabled.

How to fix it

Upgrade OpenSSH to version 10.4 or later wherever sshd is used. If a vendor distribution backports the fix, install the vendor-provided fixed package and verify the changelog references the DisableForwarding and PermitTunnel precedence fix. As an immediate mitigation, avoid configurations that combine DisableForwarding=yes with PermitTunnel=yes. Explicitly set PermitTunnel=no for users, groups, and Match blocks where tunnel forwarding is not required. Review sshd_config, included configuration files, and Match-specific policy because effective SSH settings may differ by user, group, source address, or other criteria. Restart or reload sshd after configuration changes using the platform-supported method, and ensure active sessions are reviewed if tunnel forwarding was previously possible.

How to confirm the fix worked

Confirm the installed OpenSSH server version is 10.4 or later, or that the operating-system package includes the vendor backport for this issue. Review the effective sshd configuration with sshd -T and, where relevant, include Match-context testing using options such as -C user=<user>,host=<host>,addr=<addr> to verify that PermitTunnel is not enabled where DisableForwarding is intended to prohibit forwarding. Attempt a controlled SSH tunnel-forwarding test against a non-production or authorized target account subject to the policy and verify that tunnel creation is rejected. Inspect active network interfaces and routing state for unexpected tun/tap devices associated with sshd sessions. Confirm logging, audit, and network telemetry can identify SSH sessions that create or use tunnel interfaces.

Typical attack path

1. Scan for or identify reachable SSH services running OpenSSH before 10.4.
2. Obtain or use valid SSH authentication material for an account on the target service.
3. Confirm the server policy allows PermitTunnel while also relying on DisableForwarding to suppress forwarding.
4. Initiate an SSH tunnel request, such as tunnel device forwarding, through the authenticated session.
5. Route traffic through the SSH-created tunnel to access otherwise restricted internal networks or services.
6. Use the tunnel for reconnaissance, lateral movement, command-and-control relay, or data movement while blending into legitimate SSH traffic.

How to detect it

To determine whether this was already exploited, focus on systems where OpenSSH before 10.4 had an effective configuration containing both DisableForwarding=yes and PermitTunnel=yes. Review sshd authentication logs for successful logins by accounts governed by those settings, especially from unusual source addresses or at unusual times. Correlate those sessions with host telemetry showing creation of tun/tap interfaces, access to /dev/net/tun, route changes, or sshd processes associated with tunnel devices. On Linux, useful sources include /var/log/auth.log, /var/log/secure, journald entries for sshd, auditd logs for /dev/net/tun access, process execution telemetry, network interface state history, firewall logs, and NetFlow or VPC flow logs showing the SSH server initiating unexpected connections to internal destinations. On BSD or Unix-like systems, review auth logs, system logs, interface creation events, and packet-filter logs. Because ordinary SSH logs may not clearly record tunnel setup at default verbosity, absence of a clear tunnel log entry does not prove non-exploitation; correlation with network interface, routing, and traffic behavior is important. Look for SSH sessions followed by new tun interfaces, unusual internal scans, administrative protocol access, or long-lived SSH connections carrying atypical traffic volume.

• DisableForwarding yes
• DisableForwarding=yes
• PermitTunnel yes
• PermitTunnel=yes
• /dev/net/tun
• comm="sshd" name="tun"
• comm="sshd" path="/dev/net/tun"
• type=PATH msg=audit
• tun0
• tun1
• tap0
• tap1
• Tunnel device
• tun_open
• sshd -T
• Accepted publickey
• Accepted password

What your security team should do

• Inventory SSH servers, prioritizing internet-facing hosts, bastion hosts, jump servers, administrative gateways, and systems used for network segmentation enforcement.
• Upgrade OpenSSH to 10.4 or a vendor-fixed backported package as the preferred remediation.
• Search sshd configuration files and included snippets for combinations of DisableForwarding=yes and PermitTunnel=yes, including inside Match blocks.
• Set PermitTunnel=no wherever SSH tunneling is not explicitly required, and keep DisableForwarding=yes for accounts that should have no forwarding capability.
• Use sshd -T with representative Match conditions to validate the effective policy rather than relying only on static configuration review.
• Review recent SSH logins by accounts subject to restrictive forwarding policies and correlate them with creation of tun/tap interfaces, unusual routing changes, or unexpected internal network access.
• Increase sshd logging and host audit coverage on high-value SSH servers to capture tunnel-related activity where operationally feasible.
• Monitor network telemetry for SSH sessions followed by unusual east-west traffic from the SSH server to internal services.
• Treat this as moderate urgency overall because there is no KEV listing, no known ransomware use, low EPSS, and no public exploit maturity indicated, but escalate priority where SSH servers are used as security boundaries.