CVE-2026-73283: OpenSSH Authentication Bypass Vulnerability

CVE-2026-73283 Overview

CVE-2026-73283 is a control flow issue [CWE-670] in OpenSSH versions before 10.5. The restrict keyword in authorized_keys was intended to disable all forwarding and interactive features for a given key. However, the restriction was not applied to tunnel forwarding. A local authenticated user whose key was configured with restrict could still establish tun/tap tunnel forwarding, bypassing the intended security boundary.

Critical Impact
A misconfigured or unexpected tunnel forwarding channel can be established by a key marked restrict, undermining the least-privilege model administrators rely on when provisioning restricted SSH keys.

Affected Products

OpenSSH sshd versions prior to 10.5
Systems using authorized_keys with the restrict keyword for key hardening
Deployments relying on the restrict option to block tunnel (PermitTunnel) forwarding

Discovery Timeline

2026-08-11 - CVE-2026-73283 published to the National Vulnerability Database (NVD)
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-73283

Vulnerability Analysis

OpenSSH provides the restrict keyword in authorized_keys as a shorthand to disable every current and future forwarding and interactive feature associated with a key. Administrators use it to constrain automation keys and reduce exposure when a key is misused or compromised.

The defect is scoped narrowly. The restrict handler covered X11, agent, port, and stream forwarding, along with PTY allocation and user RC execution. It did not extend to tun/tap device forwarding controlled by the server's PermitTunnel setting. A client authenticating with a restrict-marked key could still request a tunnel forwarding channel and, if the server permitted tunnels globally, obtain one.

Exploitation requires an existing valid key on the target, the ability to reach sshd, and a server configured with PermitTunnel enabled. Impact is limited to unintended network tunneling from an authenticated principal; confidentiality and availability are not directly affected, but the integrity of access controls is undermined.

Root Cause

The issue is a missing constraint propagation. The restrict option did not include tunnel forwarding in the set of features it disables, so tunnel requests were evaluated only against the global sshd_config policy rather than the per-key restriction.

Attack Vector

The attack vector is local and requires prior authentication. An attacker with access to a restrict-marked key requests a tun/tap forwarding channel during SSH session setup. See the OpenSSH 10.5 Release Notes for the upstream description and fix.

Detection Methods for CVE-2026-73283

Indicators of Compromise

Unexpected sshd log entries indicating tunnel device allocation for sessions authenticated with keys carrying the restrict option
Presence of tun or tap interfaces created by user contexts that should be limited by restrict
Outbound traffic on unexpected virtual interfaces originating from accounts intended to be restricted

Detection Strategies

Audit authorized_keys files across managed hosts for entries containing restrict and correlate with the running OpenSSH version
Enable verbose sshd logging (LogLevel VERBOSE) and alert on debug1: sys_tun_open or tunnel-related messages tied to restricted keys
Review sshd_config for PermitTunnel values other than no on hosts that host restricted automation keys

Monitoring Recommendations

Track creation of tun/tap interfaces via kernel or auditd rules on Linux endpoints
Baseline expected forwarding behavior per service account and alert on deviations
Feed OpenSSH authentication and channel-open events into a centralized log pipeline for correlation

How to Mitigate CVE-2026-73283

Immediate Actions Required

Upgrade OpenSSH sshd to version 10.5 or later on all affected hosts
Set PermitTunnel no in sshd_config unless tunnel forwarding is explicitly required
Inventory all keys using the restrict option and confirm none are able to open tunnel channels post-remediation

Patch Information

The issue is resolved in OpenSSH 10.5. Refer to the OpenSSH 10.5 Release Notes for upstream fix details. Distributions that ship OpenSSH should provide backported packages; apply them through the standard package manager.

Workarounds

Explicitly append permittunnel="no" and tunnel="none" restrictions where supported, or set PermitTunnel no globally in sshd_config
Restrict network access to sshd for accounts tied to restrict keys using firewall rules or Match blocks
Rotate and reissue automation keys after patching to validate that tunnel forwarding is denied

bash

# Configuration example: disable tunnel forwarding globally in sshd_config
PermitTunnel no

# Then reload sshd
sudo systemctl reload sshd