{"id":"CVE-2026-102823","aliases":["DEBIAN-CVE-2026-102823","EUVD-2026-89206","GHSA-47hw-gvq5-r2gm","RHSA-2026:74586","RUSTSEC-2026-0492","UBUNTU-CVE-2026-102823"],"status":"published","title":"russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00317,"percentile":0.24982,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-20"],"published":"2026-09-29T18:25:58Z","modified":"2026-11-12T08:00:03Z","fixes":[{"ecosystem":"crates.io","package":"russh","fixed_in":["0.63.1"],"sources":["ghsa","osv"]},{"ecosystem":"Debian:14","package":"rust-russh","fixed_in":["0.64.1-1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"russh","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.63.0"},{"fixed":"0.63.1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"rust-russh","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.64.1-1"}]}],"versions":["0.57.1-1","0.57.1-2"]},{"source":"osv","ecosystem":"crates.io","package":"russh","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.63.1"}]}]},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"openshell","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:0.1.2-0.2.hum1"}]}],"bundled":4},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"openshell-gateway","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:0.1.2-0.2.hum1"}]}],"bundled":4},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"python3-openshell","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:0.1.2-0.2.hum1"}]}],"bundled":4},{"source":"osv","ecosystem":"crates.io","package":"russh","ranges":[{"type":"SEMVER","events":[{"introduced":"0.0.0-0"},{"fixed":"0.63.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"rust-russh","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.57.1-2"]}],"products":[{"vendor":"eugeny","product":"russh"}],"references":[{"url":"https://github.com/Eugeny/russh/security/advisories/GHSA-47hw-gvq5-r2gm","tags":["x_refsource_CONFIRM","exploit","advisory","web","article","report"]},{"url":"https://github.com/Eugeny/russh/commit/3430fd26ecafc0dc3705210f5f39a9119fa22774","tags":["x_refsource_MISC","fix","web","article","report"]},{"url":"https://github.com/Eugeny/russh/releases/tag/v0.63.1","tags":["x_refsource_MISC","web","article","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-102823","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-47hw-gvq5-r2gm"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/102xxx/CVE-2026-102823.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-102823","tags":["advisory"]},{"url":"https://github.com/Eugeny/russh","tags":["package"]},{"url":"https://access.redhat.com/errata/RHSA-2026:74586","tags":["advisory"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-102821","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-102823","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-102824","tags":["report"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-102825","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_74586.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2543501","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-102821","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-102821","tags":["advisory"]},{"url":"https://github.com/Eugeny/russh/commit/a282af361ac99bc76b80876d1aae128e89dbf66b","tags":["article"]},{"url":"https://github.com/Eugeny/russh/releases/tag/v0.63.2","tags":["article"]},{"url":"https://github.com/Eugeny/russh/security/advisories/GHSA-35g8-35p8-c8fw","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2543503","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-102823","tags":["advisory","report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2543498","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-102824","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-102824","tags":["advisory"]},{"url":"https://github.com/Eugeny/russh/commit/8da8967f196472576b1565d518a0ed60fce60f0c","tags":["article"]},{"url":"https://github.com/Eugeny/russh/releases/tag/v0.63.0","tags":["article"]},{"url":"https://github.com/Eugeny/russh/security/advisories/GHSA-w3jg-pjxf-73p4","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2543507","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-102825","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-102825","tags":["advisory"]},{"url":"https://github.com/Eugeny/russh/commit/f8fd0b11a393364dc7f01a182482d86adafdd653","tags":["article"]},{"url":"https://github.com/Eugeny/russh/releases/tag/v0.62.6","tags":["article"]},{"url":"https://github.com/Eugeny/russh/security/advisories/GHSA-g6xm-f9xp-qq35","tags":["article"]},{"url":"https://crates.io/crates/russh","tags":["package"]},{"url":"https://rustsec.org/advisories/RUSTSEC-2026-0492.html","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-102823","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-102823","title":"russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T18:25:58.084Z","modified":"2026-10-02T12:20:10.605Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-20"],"updated_at":"2026-11-02T13:38:54.394896Z"}],"euvd":[{"id":"EUVD-2026-89206","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T18:25:58Z","modified":"2026-10-02T12:20:10Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T17:27:43.134956Z"}],"ghsa":[{"id":"GHSA-47hw-gvq5-r2gm","title":"russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened","description":"### Summary\nCVE-2026-68930 was fixed by adding `Session::is_established_channel()` in `russh/src/server/encrypted.rs`, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on `enc.channels.get(\u0026channel).is_some_and(|c| c.confirmed)` before invoking any `Handler` callback. The identical validation was never added to the CLIENT side (`russh/src/client/encrypted.rs`), which processes channel-scoped messages sent by the SSH SERVER once the client has authenticated.\n\n### Details\nIn `client_read_authenticated` (`russh/src/client/encrypted.rs`, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST sub-types exit-status/exit-signal/xon-xoff, the code only optionally forwards the event to the internal per-channel mpsc sender via `if let Some(chan) = self.channels.get(\u0026channel_num) { ... }` (a no-op if the channel is unknown), but then **unconditionally** calls the corresponding public `Handler` trait method (`client.data(...)`, `client.exit_status(...)`, `client.channel_close(...)`, `client.channel_success(...)`, etc.) regardless of whether `channel_num` corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with `Error::Inconsistent` if unknown) and CHANNEL_WINDOW_ADJUST (returns early with `Ok(())` if unknown) correctly validate channel existence before acting.\n\nCorroborating evidence this check was intended but never wired up: `crate::Error` defines a dedicated `WrongChannel` variant documented as \"Message received/sent on unopened channel\" (`russh/src/lib_inner.rs`, ~line 144-146), yet a repo-wide search shows this variant is never constructed or returned anywhere in the codebase — dead code left over from (or intended for) exactly this validation.\n\nBecause `Session::new_channel_id()` (`russh/src/session.rs`, ~line 708) allocates channel IDs sequentially starting at 1, a malicious or compromised SSH server can trivially predict the ID of the client's next channel and inject spoofed lifecycle events for it before or interleaved with the real channel-open exchange, or replay events for already-closed channel IDs.\n\n### PoC\nMany real-world consumers of russh-as-a-client (deployment/orchestration tools, CI runners connecting to build/bastion hosts, git-over-ssh style tooling, database/tunnel clients) implement the `client::Handler` trait directly and key their own state (e.g. `HashMap\u003cChannelId, CommandState\u003e`, exit-code trackers, per-channel byte counters, completion futures) off the channel IDs the library hands them, trusting the documented contract that events like \"The remote process has exited\" (`exit_status`) or \"Called when the server closes a channel\" (`channel_close`) only fire for a channel the application itself opened.\n\nA malicious, MITM'd (via a compromised/rogue jump host the client is configured to trust), or simply hostile SSH server can send `SSH_MSG_CHANNEL_REQUEST` (exit-status/exit-signal), `SSH_MSG_CHANNEL_DATA`, `SSH_MSG_CHANNEL_CLOSE`, `SSH_MSG_CHANNEL_SUCCESS`/`FAILURE`, or `SSH_MSG_CHANNEL_OPEN_FAILURE` for an arbitrary/predicted/never-opened channel ID at any point after authentication completes. Because the library invokes the `Handler` callback unconditionally, this reaches application code with an ID it never registered.\n\n### Impact\n(1) A reliable, purely protocol-level trigger for an application panic/DoS in any client that indexes per-channel state by `ChannelId` without itself re-checking channel validity — the exact class of bug CVE-2026-68930 fixed server-side; and (2) lets the server spoof exit-status/exit-signal/close/success/failure notifications for a channel the client has not yet opened or has already released, desynchronizing the client's command-completion bookkeeping (e.g. reporting a forged exit code 0 for a not-yet-run remote command, or a premature `channel_close` before real output/exit-status has arrived) — a business-logic-level integrity violation of the SSH channel lifecycle that automation built on russh implicitly relies on.\n\nSuggested fix: add the same `is_established_channel()`-style gate already used in `server/encrypted.rs` to `client/encrypted.rs`'s `client_read_authenticated`, checking `self.channels.get(\u0026channel_num)` before invoking any `Handler` callback (not just the mpsc forward), for every channel-scoped message type.\n\nFor credit/changelog purposes, please use: Yazan Balawneh, Cystack.ps","status":"published","published":"2026-09-30T23:27:17Z","modified":"2026-09-30T23:27:18Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-20"],"updated_at":"2026-11-02T14:41:23.783773Z"}],"nvd":[{"id":"CVE-2026-102823","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T19:17:24.367Z","modified":"2026-10-02T13:17:25.65Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-20"],"updated_at":"2026-11-02T14:12:52.759595Z"}],"osv":[{"id":"CVE-2026-102823","title":"russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T18:25:58.084Z","modified":"2026-11-12T08:11:07.434997782Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-20"],"updated_at":"2026-11-12T08:43:51.58637Z"},{"id":"DEBIAN-CVE-2026-102823","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T19:17:24.367Z","modified":"2026-10-14T16:00:05.976689704Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:45:48.903138Z"},{"id":"GHSA-47hw-gvq5-r2gm","title":"russh: Client-side channel-scoped Handler callbacks fire for channel IDs the client never opened","description":"### Summary\nCVE-2026-68930 was fixed by adding `Session::is_established_channel()` in `russh/src/server/encrypted.rs`, which gates every channel-scoped SERVER-side message (CHANNEL_REQUEST, CHANNEL_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_WINDOW_ADJUST, CHANNEL_EXTENDED_DATA) on `enc.channels.get(\u0026channel).is_some_and(|c| c.confirmed)` before invoking any `Handler` callback. The identical validation was never added to the CLIENT side (`russh/src/client/encrypted.rs`), which processes channel-scoped messages sent by the SSH SERVER once the client has authenticated.\n\n### Details\nIn `client_read_authenticated` (`russh/src/client/encrypted.rs`, ~lines 431-757), for CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and the CHANNEL_REQUEST sub-types exit-status/exit-signal/xon-xoff, the code only optionally forwards the event to the internal per-channel mpsc sender via `if let Some(chan) = self.channels.get(\u0026channel_num) { ... }` (a no-op if the channel is unknown), but then **unconditionally** calls the corresponding public `Handler` trait method (`client.data(...)`, `client.exit_status(...)`, `client.channel_close(...)`, `client.channel_success(...)`, etc.) regardless of whether `channel_num` corresponds to any channel the client ever opened or that was ever confirmed. Only CHANNEL_OPEN_CONFIRMATION (closes the connection with `Error::Inconsistent` if unknown) and CHANNEL_WINDOW_ADJUST (returns early with `Ok(())` if unknown) correctly validate channel existence before acting.\n\nCorroborating evidence this check was intended but never wired up: `crate::Error` defines a dedicated `WrongChannel` variant documented as \"Message received/sent on unopened channel\" (`russh/src/lib_inner.rs`, ~line 144-146), yet a repo-wide search shows this variant is never constructed or returned anywhere in the codebase — dead code left over from (or intended for) exactly this validation.\n\nBecause `Session::new_channel_id()` (`russh/src/session.rs`, ~line 708) allocates channel IDs sequentially starting at 1, a malicious or compromised SSH server can trivially predict the ID of the client's next channel and inject spoofed lifecycle events for it before or interleaved with the real channel-open exchange, or replay events for already-closed channel IDs.\n\n### PoC\nMany real-world consumers of russh-as-a-client (deployment/orchestration tools, CI runners connecting to build/bastion hosts, git-over-ssh style tooling, database/tunnel clients) implement the `client::Handler` trait directly and key their own state (e.g. `HashMap\u003cChannelId, CommandState\u003e`, exit-code trackers, per-channel byte counters, completion futures) off the channel IDs the library hands them, trusting the documented contract that events like \"The remote process has exited\" (`exit_status`) or \"Called when the server closes a channel\" (`channel_close`) only fire for a channel the application itself opened.\n\nA malicious, MITM'd (via a compromised/rogue jump host the client is configured to trust), or simply hostile SSH server can send `SSH_MSG_CHANNEL_REQUEST` (exit-status/exit-signal), `SSH_MSG_CHANNEL_DATA`, `SSH_MSG_CHANNEL_CLOSE`, `SSH_MSG_CHANNEL_SUCCESS`/`FAILURE`, or `SSH_MSG_CHANNEL_OPEN_FAILURE` for an arbitrary/predicted/never-opened channel ID at any point after authentication completes. Because the library invokes the `Handler` callback unconditionally, this reaches application code with an ID it never registered.\n\n### Impact\n(1) A reliable, purely protocol-level trigger for an application panic/DoS in any client that indexes per-channel state by `ChannelId` without itself re-checking channel validity — the exact class of bug CVE-2026-68930 fixed server-side; and (2) lets the server spoof exit-status/exit-signal/close/success/failure notifications for a channel the client has not yet opened or has already released, desynchronizing the client's command-completion bookkeeping (e.g. reporting a forged exit code 0 for a not-yet-run remote command, or a premature `channel_close` before real output/exit-status has arrived) — a business-logic-level integrity violation of the SSH channel lifecycle that automation built on russh implicitly relies on.\n\nSuggested fix: add the same `is_established_channel()`-style gate already used in `server/encrypted.rs` to `client/encrypted.rs`'s `client_read_authenticated`, checking `self.channels.get(\u0026channel_num)` before invoking any `Handler` callback (not just the mpsc forward), for every channel-scoped message type.\n\nFor credit/changelog purposes, please use: Yazan Balawneh, Cystack.ps","status":"published","published":"2026-09-30T23:27:17Z","modified":"2026-11-12T08:11:07.434997782Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"cwes":["CWE-20"],"updated_at":"2026-11-12T08:43:51.58637Z"},{"id":"RHSA-2026:74586","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update","status":"published","published":"2026-10-02T10:26:00Z","modified":"2026-10-03T10:16:58Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:53:22.928316Z"},{"id":"RUSTSEC-2026-0492","title":"Client `Handler` callbacks run for channels the client never opened","description":"On the client side, russh passed channel messages from the server (data, extended data, EOF, close, success, failure, open failure and the exit-status, exit-signal and xon-xoff requests) to the application's `client::Handler` callbacks without checking that the channel number belonged to a channel the client had opened and the server had confirmed. The server side already performed this check.\n\nA malicious or compromised SSH server can therefore send these messages for any channel number, including the next number the client will allocate (they are assigned in order) or one it has already closed. An application that tracks per-channel state can be made to record a false exit status, see a channel close before its real output arrives, or panic when it looks up a channel it does not know.\n\nFrom 0.63.1 the client ignores channel messages for channels that are not established and confirmed, and handles an open failure only for a channel it is actually opening.","status":"published","published":"2026-09-30T12:00:00Z","modified":"2026-11-12T08:00:03.171769819Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-12T08:05:53.493073Z"},{"id":"UBUNTU-CVE-2026-102823","description":"Russh is a Rust SSH client and server library. Prior to 0.63.1, client_read_authenticated in russh/src/client/encrypted.rs forwards CHANNEL_DATA, CHANNEL_EXTENDED_DATA, CHANNEL_EOF, CHANNEL_CLOSE, CHANNEL_OPEN_FAILURE, CHANNEL_SUCCESS, CHANNEL_FAILURE, and CHANNEL_REQUEST subtypes exit-status, exit-signal, and xon-xoff to public client::Handler callbacks without confirming that the ChannelId belongs to a channel the client opened and established. A malicious SSH server can send lifecycle events for predicted, unopened, unconfirmed, or released channel identifiers, causing application panics or corrupting command completion and exit-code tracking. This issue is fixed in version 0.63.1.","status":"published","published":"2026-09-29T19:17:00Z","modified":"2026-10-17T12:57:56.054809267Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T16:55:58.519486Z"}]}}