CVE-2026-73283

Executive Summary

CVE-2026-73283 is a configuration-enforcement logic flaw in sshd in OpenSSH versions before 10.5. The restrict keyword used in authorized_keys was intended to disable all per-key forwarding capabilities — including tunnel forwarding — but due to an incorrect control flow, the restriction was never applied to tunnel forwarding. The primary affected population is administrators who rely on the restrict keyword to sandbox SSH keys, typically for automation, jump hosts, or third-party access. The practical impact is limited: a key holder granted a restrict-flagged key can still establish tunnel forwarding, bypassing the administrator's stated security policy, although the vulnerability is rated low severity (CVSS 2.5) and requires pre-existing key access.

Technical Analysis

The NVD description is sparse but sufficient to characterize the vulnerability class as a security feature bypass caused by an always-incorrect control flow implementation (CWE-670). The restrict keyword in OpenSSH's authorized_keys file is a consolidated directive that revokes all of the per-key permissions that are normally granted by default — for example, port forwarding, agent forwarding, X11 forwarding, and pseudo-terminal allocation. Site administrators apply it with delegated permissions to minimize the blast radius of a compromised or misused key. The vulnerability is that restrict was supposed to also govern tunnel forwarding (the creation of Layer 2/Layer 3 network tunnels through the SSH connection), but the enforcement code path does not actually apply the restriction to that feature. In other words, the boolean/flag that gates tunnel forwarding permission is never set when restrict is parsed, so the subsequent authorization check for tunnel requests passes instead of failing closed.

Because the NVD entry contains no code-level detail, function names, or diffs, the exact branching logic that fails cannot be identified from the CVE data alone. What can be reasoned from the description and the CWE mapping is that the flaw resides in the authorized-keys option parsing or in the tunneling-request authorization checks inside sshd. The attack surface is local to the authenticating principal: an attacker must already hold a private key whose corresponding public key is installed in the target account's authorized_keys with the restrict keyword. No unauthenticated, network-only exploitation is possible, which is consistent with the CVSS vector AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N. The high attack complexity likely reflects the several preconditions that must align: possession of a valid restricted key, a server that otherwise permits tunnel setup, and the absence of compensating controls.

The affected version set is stated as all OpenSSH versions before 10.5. The dataset lists no exact affected-version enumerator and no OSV packages, so the precise boundary between vulnerable and non-vulnerable builds beyond "10.5 is the first fixed version" is unknown. No patch evidence, vendor advisory, or workaround documentation was tracked at the time of writing, and the patch confidence is 0/4 (unpatched per all tracked sources).

Exploitation Scenarios

No public exploit code or PoC is available for CVE-2026-73283, and there is no indication of exploitation in the wild (EPSS 0.00083; not listed in CISA KEV). The attack chain below is therefore inferred from the vulnerability class and must be treated as a defensive-model scenario rather than a confirmed operational sequence.

1. Reconnaissance / target identification. An attacker who already possesses — or has compromised — a private key whose public half is deployed in a victim server's authorized_keys identifies that the server runs OpenSSH before 10.5 (e.g., via the SSH banner SSH-2.0-OpenSSH_*). The attacker additionally needs to know that their key carries the restrict keyword, which implies the key was intended to be capability-limited.

2. Flaw triggering. The attacker opens an SSH connection to the target and requests tunnel forwarding during session setup. Under the intended configuration, sshd should deny this request because the restrict keyword disables tunnel forwarding. Because of the control-flow defect, the tunnel-forwarding authorization path is evaluated without the restriction being applied, so the request is accepted and the tunnel is set up.

3. Payload / execution method. There is no conventional "payload" in this vulnerability. The execution mechanism is a configuration enforcement failure: the SSH client asks for a network tunnel (tunnel forwarding at the protocol/session level) and sshd honors it even for keys that should be restricted. No code injection, memory corruption, or authentication bypass occurs.

4. Post-exploitation impact. The key holder can now forward traffic through the server's network stack as if the tunnel were an approved connection. Depending on the connecting account's network privileges, this could allow the attacker to bridge onto internal network segments, pivot toward other hosts, or exfiltrate/infiltrate data over the tunnel — all while the administrator's logging and audit trail reflects only a normal SSH session. The ceiling is modest, however: confidentiality is not compromised by the flaw itself, availability is unaffected, and the integrity impact is limited to the policy deviation (the tunnel itself).

Organizations should assume the following test case when validating the issue: install a key with the restrict option in a test authorized_keys, connect with that key, and attempt to establish a tunnel; a vulnerable server will allow it where a fixed server should reject it.

Impact Assessment

The official CVSS score is 2.5 (Low) with vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N. Reading the vector in detail:

• AV:L / PR:L — the adversary must already have a valid restricted SSH key and local-level interaction with the target service; this is not a wormable or remotely triggerable flaw.
• AC:H — a combination of preconditions (specific key type, server-side tunnel configuration, account privileges) must align for the bypass to matter.
• UI:N / S:U — no user interaction is required and the compromise is contained within the SSH server's security scope.
• C:N / I:L / A:N — confidentiality and availability are untouched; integrity is slightly impacted because the enforcement of the security policy fails.

In business terms, this is a governance and trust-boundary issue rather than an availability or data-breach issue. The most likely victims are enterprises that use restrict-tagged keys to delegate operational access (automation accounts, vendor access, jump-host accounts) and that depend on the keyword as a compensating control for network segmentation. The blast radius is restricted to systems running OpenSSH before 10.5 with such keys; environments that do not use restrict or that disable tunnel forwarding at the server configuration level are unaffected in practice. The EPSS probability score of 0.00083 (0.3rd percentile of exploited CVEs) and absence from the CISA KEV catalog both indicate that real-world exploitation pressure is currently very low.

Detection Guidance

The detection rules below are heuristic and should be tuned to the local environment. Note that SSH session content is encrypted; network-layer rules can only flag the presence and banner of a vulnerable server, not the tunnel data itself. Host-level rules rely on sshd authentication logs and on the system artifacts generated when a tunnel device is allocated. Field names and log examples are illustrative — verify against the actual logging schemas in the environment before deployment.

Sigma Rule

title: OpenSSH Restricted Key Tunnel Forwarding Attempt
id: 9c7d1f4a-5e2b-4c10-8f6a-2b88a0c3d7e1
status: experimental
description: >
  Detects sshd authentication log entries in which an SSH session is
  associated with a restricted authorized-key but also indicates tunnel
  forwarding activity, which should not occur per the restrict keyword.
  Heuristic indicator for CVE-2026-73283.
logsource:
  product: linux
  service: sshd
detection:
  selection_restricted:
    message|contains:
      - "restrict"
      - "authorized_keys"
  selection_tunnel:
    message|contains:
      - "tunnel"
      - "tun"
      - "forwarding"
  condition: selection_restricted and selection_tunnel
falsepositives:
  - Legitimate administrator sessions where tunnel forwarding is explicitly permitted through other options
  - Log aggregation platforms that join unrelated log lines
level: medium
tags:
  - attack.t1562
  - cve.2026-73283

YARA Rule

rule OpenSSH_AuthorizedKeys_Restrict_Tunnel_ByPass
{
    meta:
        author = "Valters IT Threat Intelligence"
        description = "Scans authorized_keys files for the coexistence of the restrict keyword and tunnel-related tokens, a configuration pattern affected by CVE-2026-73283."
        cve = "CVE-2026-73283"
        version = "1.0"
    strings:
        $restrict = "restrict" ascii nocase
        $tunnel   = "tunnel" ascii nocase
        $tun_dev  = "tun" ascii nocase
        $key_type = "ssh-rsa" ascii nocase
        $key_type2 = "ssh-ed25519" ascii nocase
    condition:
        uint16(0) != 0x5A4D and
        filesize < 2MB and
        #restrict > 0 and
        (#tunnel > 0 or #tun_dev > 0) and
        (#key_type > 0 or #key_type2 > 0)
}

Suricata IDS Rule

alert tcp any any -> any 22 (msg:"CVE-2026-73283 - OpenSSH pre-10.5 vulnerable banner observed on SSH service"; flow:established,to_client; content:"SSH-2.0-OpenSSH"; pcre:"/SSH-2\.0-OpenSSH_(?:[1-9](?:\.[0-9]+)?|10\.(?:[0-4](?:\.[0-9]+)?))(?:\r?\n|$)/"; classtype:policy-violation; sid:202673283; rev:1;)

This rule flags SSH servers that present a banner consistent with an affected release. Because the tunnel misuse itself is encrypted, the rule is a reconnaissance/asset-inventory indicator, not an exploitation detector. Adjust the destination port and exclude monitored honeypot or decoy assets as appropriate.

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where process.name == "sshd" and event.outcome == "success" and message like "*restrict*" ]
  [ process where process.name == "sshd" and (args in ("-w", "-T") or command_line like "*tun*") ]

The first event identifies a successful SSH authentication associated with a restricted key; the second correlates subsequent sshd activity indicating a tunnel (device allocation or tunnel-related command-line arguments). If the EQL engine does not support args in (...), replace with an equivalent command_line pattern match.

Splunk SPL Query

index=linux sourcetype=linux_secure sshd
| regex _raw="(?i)(restrict.*tunnel|tunnel.*restrict|Tunnel.*forwarding)"
| eval suspicious_restricted_tunnel = if(match(_raw, "(?i)restrict"), "yes", "no")
| table _time, host, src_ip, user, process, suspicious_restricted_tunnel, _raw
| sort - _time

This search pulls sshd log entries that simultaneously reference restriction and tunnel activity, and explicitly marks restricted-key sessions with a dedicated field so SOC analysts can pivot to the originating user and source address.

Wazuh OSSEC Rule

<group name="openssh,">
  <rule id="100283" level="8">
    <decoded_as>sshd</decoded_as>
    <regex>(?i)restrict.*tunnel|tunnel.*restrict|Tunnel.*forwarding</regex>
    <description>OpenSSH: tunnel forwarding activity detected in association with a restricted authorized key (CVE-2026-73283)</description>
    <mitre id="T1562"/>
    <group>policy_violation</group>
  </rule>
</group>

Place the rule inside the active local_rules.xml or a dedicated OpenSSH ruleset file, then validate with ossec-analysisd -t. The rule fires at level 8 (high) when the regex matches sshd log content combining restriction and tunnel tokens.

Mitigation & Patch Guidance

Patch confidence is 0/4 — no patch evidence is tracked from any source, and the dataset lists no vendor fix, workaround, or affected-version enumerator. The following guidance is therefore layered and assumes the worst case: the flaw is present in all OpenSSH builds before 10.5 and remains unfixed in deployed environments.

1. Immediate mitigations.

   • Audit every authorized_keys file on SSH servers for keys carrying the restrict keyword. For each such key, determine whether tunnel forwarding was intentionally granted.
   • Explicitly disable tunnel forwarding at the server administrative level for any key that must remain restrict-flagged. Do not rely on the restrict keyword alone as the enforcement point.
   • Review and restrict the network account privileges assigned to restrict-tagged keys so that even if a tunnel is opened, the key holder cannot reach high-value segments.
   • Monitor authentication logs and tunnel-device allocation events on sensitive hosts; alert on any tunnel activity originating from accounts whose keys are flagged restrict.

2. Patch / upgrade steps.

   • The NVD description indicates the flaw exists in OpenSSH before 10.5, implying that OpenSSH 10.5 is the fixing release. Because no vendor patch advisory was tracked, verify on the official OpenSSH release site whether 10.5 (or a later release) has been published before upgrading.
   • Upgrade to OpenSSH 10.5 or newer on all affected systems, following the vendor's release notes and regression-testing guidance for your distribution.
   • If upgrading requires a maintenance window, prioritize internet-facing SSH services and jump hosts where restricted keys are commonly used.

3. Long-term hardening.

   • Adopt a key-management policy that treats restricted keys as "allowlist" entitlements and requires periodic re-approval and rotation.
   • Enforce network segmentation so that SSH tunnels cannot cross trust boundaries by default; combine with egress filtering and monitoring of unusual long-lived connections.
   • Automate configuration drift checks on authorized_keys so that newly added keys automatically trigger a policy review.
   • Subscribe to OpenSSH release announcements and CVE feeds so that patch-confidence gaps are re-evaluated as soon as vendor information appears.

References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-73283
• CWE-670 Always-Incorrect Control Flow Implementation: https://cwe.mitre.org/data/definitions/670.html
• OpenSSH Official Release Notes: https://www.openssh.com/releasenotes.html
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-73283 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• MITRE ATT&CK T1562 — Impair Defenses: https://attack.mitre.org/techniques/T1562/

At the time of writing, no known threat-actor campaigns, exploit-in-the-wild evidence, or public exploit code are associated with this CVE. The report should be updated when the OpenSSH project publishes the upstream fix or when additional technical details (patched code diff, advisory) become available.