CVE-2026-102823

Executive Summary

CVE-2026-102823 is an improper input validation (CWE-20) flaw in Russh, a Rust SSH client and server library, present in versions prior to 0.63.1. The vulnerability allows a malicious or compromised SSH server to send channel lifecycle events referencing channel identifiers the client never opened or confirmed, causing application panics and corruption of command completion and exit-code tracking. Any application embedding a vulnerable Russh client (automation frameworks, deployment tooling, CI/CD runners, or agentless management platforms that connect outward via SSH) is exposed with a CVSS base score of 7.5 (High).

Technical Analysis

Russh is a pure-Rust implementation of the SSH protocol, functioning as both client and server library. The defect resides in the client's encrypted-packet processing path, in the function client_read_authenticated located at russh/src/client/encrypted.rs. This function is responsible for handling inbound channel-related SSH messages after authentication has completed.

Per the NVD description, the affected function forwards the following SSH message types to public client::Handler callbacks without verifying that the referenced ChannelId belongs to a channel that the client itself opened and established:

• CHANNEL_DATA
• CHANNEL_EXTENDED_DATA
• CHANNEL_EOF
• CHANNEL_CLOSE
• CHANNEL_OPEN_FAILURE
• CHANNEL_SUCCESS
• CHANNEL_FAILURE
• CHANNEL_REQUEST subtypes: exit-status, exit-signal, and xon-xoff

The SSH channel multiplexing model assigns a local channel identifier to each channel opened by the client. A well-behaved server echoes those identifiers when sending channel-scoped messages. Because the vulnerable code path performs no ownership or state validation of the incoming ChannelId, a hostile server can transmit lifecycle events for identifiers that are "predicted, unopened, unconfirmed, or released." In other words, the server can guess or enumerate plausible channel IDs and push events against them.

The security-relevant consequence is twofold. First, an application may panic when a callback receives data for a channel it does not track, terminating the client process (denial of service / availability disruption on the client side). Second, and more subtly, exit-code and command-completion integrity is corrupted: stray exit-status, exit-signal, or CHANNEL_CLOSE messages associated with channels that were never validly established can cause the client application to record incorrect completion state for commands. This integrity impact is reflected by the CVSS vector subscores—I:H (High integrity impact) with C:N and A:N—while the scope remains unchanged (S:U).

The attack requires no privileges (PR:N), no user interaction (UI:N), and is network-reachable (AV:N) with low attack complexity (AC:L). The attacker is not an anonymous network peer but the authenticated SSH server endpoint the client deliberately connects to; the trust model of SSH assumes the server is cooperating, and this flaw breaks that assumption for the channel state machine.

Exploitation Scenarios

The exploitation model for CVE-2026-102823 is that of a malicious SSH server, not a malicious client. This is a reverse of the common SSH attack narrative.

1. Reconnaissance / target identification. An adversary who controls or can impersonate an SSH server (via a compromised bastion host, DNS hijack, ARP/route manipulation, or a deliberately malicious "test" endpoint) identifies a victim client application that uses a vulnerable Russh build. Because the attack surface is the client's outbound SSH session, reconnaissance focuses on knowing which upstream endpoints a target's tooling connects to. No scanning of the victim is required—the victim initiates the connection.

2. Triggering the flaw class. After a successful SSH handshake and authentication, the malicious server sends channel-scoped SSH messages (CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, xon-xoff) that reference channel identifiers the client never opened, never confirmed, or has already released. The client's client_read_authenticated path accepts these without validating ChannelId ownership and dispatches them into the public client::Handler callbacks.

3. Payload / execution method. The "payload" is not code injection but a stream of malformed channel state transitions. By choosing identifiers that collide with or precede legitimate channel allocations, the server influences which callback path fires and with what data. Because the flaw is an input-validation gap rather than a memory-safety bug, the immediate primitive is logic/state manipulation and potential panic.

4. Post-exploitation impact. Two outcomes are described. (a) Application panic: the client process aborts when callbacks encounter untracked channels, which can interrupt deployment jobs, CI pipelines, or management agents and may leave remote work half-completed. (b) Integrity corruption: forged exit-status, exit-signal, or completion events desynchronize the client's command completion and exit-code accounting. Downstream automation that branches on exit codes may treat a failed command as successful (or vice versa), yielding supply-chain-style consequences such as shipping an unverified build, skipping a validation gate, or masking a failed remote operation.

No public proof-of-concept, exploit code, or Nuclei template is available. The attack chain above is inferred from the vulnerability class and the NVD description; no specific wire-level byte sequences or additional function names are asserted.

Impact Assessment

Successful exploitation yields High integrity impact (I:H) and no direct confidentiality or availability impact at the CVSS scope level (C:N, A:N), with no scope change (S:U). The 7.5 base score is driven by the trivially reachable network attack vector (AV:N), low complexity (AC:L), lack of required privileges (PR:N), and absence of user interaction (UI:N).

Practically, availability is still a concern at the application layer: the described "application panics" can terminate a client process, disrupting automation even though CVSS categorizes the formal availability impact as None. The more serious concern is integrity of program control: corrupted exit-code tracking can cause automation platforms to misclassify command outcomes. Organizations that use Russh-based tooling for configuration management, artifact distribution, remote execution, or orchestration should treat this as a trust-boundary defect in their outbound SSH path.

Blast radius is bounded by which systems run the vulnerable client and which servers they contact. A single malicious or compromised upstream endpoint can affect every client that connects to it. Because the flaw is triggered post-authentication, standard host-key pinning mitigates impersonation but does not protect against a legitimately authenticated yet malicious server.

Detection Guidance

Sigma Rule

title: Russh Client Channel State Anomaly - Untracked ChannelId Events
id: 8f2c1a44-7d5e-4b21-9c3a-russh102823
status: experimental
description: Detects Russh client process crashes/panics consistent with CVE-2026-102823, where malformed SSH channel events (exit-status, exit-signal, xon-xoff, channel close/data) reference untracked channel identifiers.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-102823
author: Threat Intelligence
date: 2026-01-01
logsource:
  product: linux
  service: syslog
detection:
  selection_panic:
    - "panicked at"
    - "russh/src/client/encrypted.rs"
    - "client_read_authenticated"
  selection_channel:
    - "ChannelId"
    - "CHANNEL_OPEN_FAILURE"
    - "CHANNEL_SUCCESS"
  condition: selection_panic and selection_channel
falsepositives:
  - Legitimate application crashes unrelated to SSH channel handling
level: medium
tags:
  - attack.t1190
  - cve.2026.102823

YARA Rule

rule CVE_2026_102823_Russh_Channel_Validation
{
    meta:
        description = "Detects Russh builds prior to 0.63.1 lacking ChannelId ownership validation in client_read_authenticated"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-102823"
        cve = "CVE-2026-102823"
        date = "2026-01-01"

    strings:
        $fn      = "client_read_authenticated" ascii
        $path    = "russh/src/client/encrypted.rs" ascii
        $m1      = "CHANNEL_OPEN_FAILURE" ascii
        $m2      = "CHANNEL_EXTENDED_DATA" ascii
        $m3      = "exit-signal" ascii
        $m4      = "xon-xoff" ascii
        $ver     = "0.63.1" ascii

    condition:
        ($fn or $path) and 2 of ($m*) and not $ver
}

Suricata IDS Rule

alert tcp any 22 -> any any (msg:"CVE-2026-102823 Possible Russh Client Channel State Manipulation (malicious SSH server)"; flow:established,from_server; content:"|00 00 00|"; depth:4; byte_test:1,>,95,0,relative; classtype:attempted-dos; reference:cve,2026-102823; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-102823; sid:1028230; rev:1;)

Elastic Detection

process where event.type == "start" and
  process.name in ("russh-client", "russh") and
  process.args : "*ssh*"
// Correlate with process crash/panic events referencing russh channel handling

Splunk SPL Query

index=app_logs sourcetype=rust:app
| search ("client_read_authenticated" OR "russh/src/client/encrypted.rs" OR "panicked at")
| stats count min(_time) as first_seen max(_time) as last_seen by host process message
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="russh,cve-2026-102823,">
  <rule id="102823" level="10">
    <decoded_as>syslog</decoded_as>
    <regex>client_read_authenticated|russh/src/client/encrypted.rs|panicked at.*russh</regex>
    <description>CVE-2026-102823: Russh client channel processing anomaly (possible malicious SSH server channel-state attack)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations. Upgrade the embedded Russh dependency to version 0.63.1 or later, which the NVD description states fixes the issue; until that upgrade is complete, restrict outbound SSH client sessions to trusted, pinned server hosts (enforce host-key pinning and known-hosts verification), and where feasible run vulnerable Russh client workloads in sandboxed or supervised processes so a panic does not cascade. Wrap SSH-driven automation in supervisors that log and alert on client process termination rather than silently retrying.
2. Patch / upgrade steps. Update the Cargo dependency for russh to 0.63.1 or newer, rebuild dependent applications, and verify via cargo tree / lockfile inspection that no transitive dependency pins an older version. Re-test automation workflows to confirm exit-code propagation is intact. Because no vendor advisory was tracked, confirm the fixed version against the upstream repository release rather than relying on this report alone.
3. Long-term hardening. Treat the SSH server endpoint as untrusted input for state-machine purposes: validate all channel identifiers against locally tracked, opened channels before dispatch. Avoid using remote-reported exit codes as the sole gate for security-relevant decisions—corroborate with independent telemetry (e.g., artifact hashes, remote-side completion signals). Pin host keys and prefer outbound SSH only to infrastructure under organizational control. Add application-level panic recovery for client session handlers, and monitor for repeated client crashes as a potential indicator of a hostile upstream peer.

References

• NVD — CVE-2026-102823: https://nvd.nist.gov/vuln/detail/CVE-2026-102823
• CWE-20 Improper Input Validation: https://cwe.mitre.org/data/definitions/20.html
• CVSS v3.1 Specification: https://www.first.org/cvss/v3.1/specification-document
• MITRE ATT&CK T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• MITRE ATT&CK T1204 User Execution: https://attack.mitre.org/techniques/T1204/

No public proof-of-concept, exploit code, or Nuclei template is available for CVE-2026-102823. The CVE is not listed in CISA KEV, and no threat actor campaigns or exploit-in-the-wild evidence were provided. EPSS has not yet been scored by FIRST.org; no EPSS value is asserted.