CVE-2026-110928: 
OpenSSH vulnerability analysis and mitigation

CVE-2026-110928 is an improper access control vulnerability in OpenSSH where the authorized_keys restrict keyword is not applied to tunnel forwarding. When PermitTunnel is enabled on the server, a key or certificate principal marked with restrict can still open a tunnel, bypassing the intended access restriction. The CVE status is currently Reserved and was published on October 15, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium/High) (Red Hat CVE, Red Hat Bugzilla).

The root cause is classified as CWE-284 (Improper Access Control). The restrict keyword in authorized_keys is intended to disable a broad set of forwarding and other capabilities for a given key; however, the OpenSSH sshd daemon fails to enforce this restriction against tunnel forwarding (PermitTunnel). As a result, an authenticated user presenting a restrict-marked key can still negotiate a layer-3 tunnel (tun device) if PermitTunnel is enabled in sshd_config. This flaw is noted as distinct from the tunnel-related fix introduced in OpenSSH 10.5 for CVE-2026-73283. Red Hat has noted that its downstream patch openssh-10.4p1-CVE-2026-59999.patch is stricter than the upstream fix, meaning RHEL systems are not affected (Red Hat Bugzilla).

Successful exploitation allows an authenticated attacker holding a restrict-marked SSH key to establish unauthorized layer-3 tunnel forwarding through the SSH server, effectively bypassing the network-level access controls the restrict keyword is meant to enforce. This primarily affects integrity (CVSS integrity impact: High) by allowing unauthorized network traffic to be tunneled through the server, potentially enabling lateral movement, traffic pivoting, or circumvention of network segmentation controls. Confidentiality and availability are not directly impacted by this flaw. The attack requires PermitTunnel to be explicitly enabled, which is disabled by default in OpenSSH, limiting the exposed population (Red Hat Bugzilla, Red Hat CVE).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2026-110928 as of the available data. The vulnerability requires the attacker to already possess a valid (though restricted) SSH key and the target server must have PermitTunnel enabled — a non-default configuration — which significantly limits the attack surface. The CVE is still in Reserved status and has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. No EPSS score or threat actor attribution is currently available (Red Hat CVE, Feedly).

1. Prerequisite verification: Confirm the target SSH server has PermitTunnel yes (or PermitTunnel point-to-point) set in sshd_config — this is a non-default setting.
2. Obtain a restricted key: Acquire or already possess an SSH private key whose corresponding public key entry in authorized_keys includes the restrict keyword (e.g., restrict ssh-ed25519 AAAA... user@host).
3. Authenticate to the server: Connect to the target SSH server using the restricted key: ssh -i restricted_key user@target.
4. Request tunnel forwarding: Despite the restrict keyword, request a tun tunnel using the -w flag: ssh -i restricted_key -w 0:0 user@target. The server incorrectly permits the tunnel negotiation.
5. Establish network tunnel: Configure the resulting tun interface on both client and server to route traffic, effectively pivoting through the SSH server's network position and bypassing intended access controls (Red Hat Bugzilla).

• Logs: SSH daemon logs (/var/log/auth.log or journalctl -u sshd) showing tunnel channel open requests (tun channel type) from accounts or keys expected to be restricted; look for log entries containing Tunnel forwarding or tun alongside restrict-marked key fingerprints.
• Network: Unexpected tun network interfaces appearing on the SSH server (ip link show or ifconfig showing tun0, tun1, etc.) not associated with legitimate VPN services.
• Process: Unusual routing table changes or traffic on tun interfaces originating from the sshd process, detectable via netstat, ss, or ip route monitoring.
• Configuration: Presence of PermitTunnel yes in /etc/ssh/sshd_config combined with restrict entries in any user's ~/.ssh/authorized_keys file (Red Hat Bugzilla).

The primary workaround is to set PermitTunnel no in /etc/ssh/sshd_config (this is already the default) and restart sshd. Red Hat has confirmed that RHEL is not affected due to its stricter downstream patch (openssh-10.4p1-CVE-2026-59999.patch). Upstream OpenSSH users should monitor the OpenSSH project for a patched release and upgrade when available. Until a patch is applied, administrators should audit sshd_config for PermitTunnel settings and ensure restrict-marked keys are not granted tunnel access through compensating controls (Red Hat Bugzilla, Red Hat CVE).

Red Hat has publicly noted that RHEL is not affected by this vulnerability due to a stricter downstream patch already in place, and has explicitly stated that no RHEL trackers should be filed. The bug was reported via OSIDB automated import and is tracked in Red Hat Bugzilla. No significant broader community discussion, researcher commentary, or media coverage has been identified for this CVE at this time (Red Hat Bugzilla).