OpenSSH sshd: restrict keyword in authorized_keys did not cover tunnel forwarding

CVE-2026-73283Kernel, userspace & hypervisorcurated

Impact

The restrict keyword is the blunt instrument operators put in front of automation keys - backup pulls, monitoring, image sync - on the assumption it turns off every forwarding feature. It did not turn off tun/tap forwarding. A key intended to be able to do one thing could additionally stand up a layer-3 tunnel through the host, which on a datacenter node means a path from wherever that key is held into whatever the node can reach: the management VLAN, the storage network, the fabric side. Exposure only exists where the server also has PermitTunnel enabled, which is not the default, so most fleets are unaffected; check before scheduling anything. Scored 2.5, local vector, integrity only.

Who can reach it

A holder of a key listed in authorized_keys with restrict, authenticating to sshd normally. Authentication is required - this is a privilege-confinement bypass for an already-authorized key, not remote access.

What to do

Upgrade sshd to OpenSSH 10.5 and restart the daemon; existing sessions survive a restart, so this is a config-management push and service restart rather than a node drain. Before that lands, confirm whether PermitTunnel is anything other than no in sshd_config - if it is no, there is nothing to exploit - and add an explicit no-tun-forwarding option alongside restrict on the affected keys.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-73283 https://www.openssh.org/releasenotes.html#10.5

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.