CVE-2026-68930

This vulnerability is not a memory corruption issue—it's a protocol state desynchronization in russh's SSH channel lifecycle. The SSH channel open handshake requires a specific order: client sends SSH_MSG_CHANNEL_OPEN, server responds with SSH_MSG_CHANNEL_OPEN_CONFIRMATION, and only then should application callbacks fire for that channel. CVE-2026-68930 bypasses this ordering—russh dispatches Handler callbacks (including exec_request) for channel IDs that were never confirmed in the server's state table. The practical risk is that your exec_request and other channel handlers receive a ChannelId that doesn't map to a legitimate server-tracked session. Handlers written against russh almost certainly assume the channel exists in the server's state—some may dereference nil, assume session data is available, or make authorization decisions based on channel existence. The blast radius depends entirely on what your handlers do with these callbacks. This occurs in the server_read_authenticated path, meaning the attack surface is post-authentication. An authenticated peer can trigger callbacks with unconfirmed channel IDs. If your deployment is multi-tenant, assess whether channel ID manipulation could cross session boundaries—though the immediate risk is likely contained to the attacker's own session. Check the diff for version 0.62.5: determine whether the fix adds a validation guard (rejecting messages for unconfirmed channels) or corrects the underlying state tracking. A validation guard addresses the symptom; a state machine correction addresses the root cause. If only a guard was added, audit other callback dispatch sites in the codebase—similar desynchronizations may exist elsewhere. Also review your Handler implementations: legacy callbacks, abandoned hooks from previous API versions, or handlers written with assumptions about channel state are the most vulnerable to receiving unexpected callbacks.

Reviewed through automated stages and approved by a human before publication.