OpenSSH sshd: restrict in authorized_keys does not disable tunnel forwarding as documented

CVSS 2.5CVE-2026-106586Kernel, userspace & hypervisorcurated

Impact

The restrict keyword is the blanket "turn off every forwarding feature" switch operators put in front of automation keys, and before 10.6 it did not cover tunnel forwarding. A key the operator believed was locked down to a single command can still request a tun device. On a GPU cluster that matters where restricted keys exist precisely to keep a tenant or a CI runner from building a path off the host - a bastion into the management VLAN, or a node that sits on both the tenant network and the storage or fabric management network. The record rates it low integrity impact and high complexity, and exploitation requires already holding a key that the operator deliberately restricted. The record notes this is distinct from CVE-2026-73283.

Who can reach it

A user who already holds a key listed in authorized_keys with restrict, authenticating normally. Authentication is required; the flaw is that the restriction is not enforced.

What to do

Upgrade to OpenSSH 10.6 and restart sshd on bastions and any host with restricted keys. In the meantime add explicit PermitTunnel no in sshd_config, or the no-port-forwarding style options alongside restrict, rather than relying on restrict alone. Package update plus daemon restart - no drain or reboot.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-106586 https://www.openssh.com/releasenotes.html#10.6

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.