OpenSSH EUVD-2026-56892

Three specific conditions must simultaneously be true for this bypass to be relevant: (1) the target system runs OpenSSH sshd in any version prior to 10.5; (2) the attacking user possesses a valid private key whose corresponding public key entry in authorized_keys includes the restrict keyword; and (3) the administrator's intent was that restrict should prevent tunnel forwarding for that key - meaning the bypass only matters where that policy is security-relevant. Exploitation is further limited by CVSS AV:L (local/SSH session access required) and AC:H (the specific authorized_keys configuration must be present). Authentication with a valid key pair is mandatory (PR:L). Default OpenSSH deployments without restrict in any authorized_keys entry are entirely unaffected.

All available signals converge on very low real-world risk. The CVSS 3.1 base score of 2.5 (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N) reflects that exploitation requires local access, high attack complexity (specific authorized_keys configuration with restrict applied), low-privilege authenticated credentials, and yields only a limited integrity impact - no confidentiality or availability consequence. SSVC corroborates this: exploitation status is none, the attack is not automatable, and technical impact is partial. No EPSS data was provided, but the combination of zero confirmed exploitation, no POC, and the narrow preconditions (administrator must have explicitly deployed restrict to block tunnels) strongly suggests exploitation probability is negligible. This is a correctness/policy flaw rather than a remote attack surface. Organizations should prioritize this only if their security model critically depends on restrict blocking tunnel forwarding for specific key holders.

An SSH user whose public key is listed in authorized_keys with the restrict keyword - intended by the administrator to block tunnel forwarding among other capabilities - discovers the enforcement gap and invokes ssh -w any:any user@target to establish a tun-device tunnel. Because sshd in OpenSSH before 10.5 does not enforce restrict against this subsystem, the tunnel is permitted, allowing the user to route arbitrary network traffic through the server in violation of the intended access policy. No public exploit code has been identified.