CVE-2026-62949: AsyncSSH Python Package DOS Vulnerability

CVE-2026-62949 Overview

CVE-2026-62949 is a denial-of-service vulnerability in AsyncSSH, a Python package providing an asynchronous SSHv2 client and server implementation on top of the asyncio framework. Versions prior to 2.24.0 fail to reject a peer-supplied send_pktsize value of zero in channel open messages. The zero value drives SSHChannel._flush_send_buf into a synchronous loop that never yields control, freezing every current and future connection handled by the process. The vulnerability is tracked as [CWE-835] (Loop with Unreachable Exit Condition). It affects both client and server paths and is fixed in release 2.24.0.

Critical Impact
A malicious SSH server can freeze an AsyncSSH client, and an authenticated client can freeze an AsyncSSH server process, blocking all channel activity.

Affected Products

AsyncSSH versions prior to 2.24.0 (client role)
AsyncSSH versions prior to 2.24.0 (server role)
Python applications and services embedding vulnerable AsyncSSH releases

Discovery Timeline

2026-09-16 - CVE-2026-62949 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-62949

Vulnerability Analysis

The defect lives in AsyncSSH's channel setup handlers. Both _process_channel_open and _process_channel_open_confirmation in asyncssh/connection.py accept the peer-supplied send_pktsize field without validation. A previously commented-out check that raised ProtocolError('Invalid maximum packet size') left zero values permissible.

When application data reaches SSHChannel._flush_send_buf in asyncssh/channel.py, the sender loop slices data by the packet size. A zero packet size causes each iteration to slice and remove zero bytes, and the send window is never reduced. Because the loop condition never becomes false and no await executes, the asyncio event loop stalls. All coroutines scheduled on that loop, including unrelated SSH connections, stop making progress.

Root Cause

The root cause is missing input validation on an attacker-controlled protocol field combined with a synchronous send-buffer loop that lacks any yield point when its work quantum is zero.

Attack Vector

A malicious SSH server can send SSH_MSG_CHANNEL_OPEN_CONFIRMATION with send_pktsize=0 before the first channel write, freezing the AsyncSSH client. On the server side, any authenticated client can send SSH_MSG_CHANNEL_OPEN with send_pktsize=0 and hang the process, denying service to all other connected sessions.

python

# Security patch in asyncssh/connection.py
        send_window = packet.get_uint32()
        send_pktsize = packet.get_uint32()

-        #if send_pktsize == 0:
-        #    raise ProtocolError('Invalid maximum packet size')
+        if send_pktsize == 0:
+            raise ProtocolError('Invalid maximum packet size')

        # Work around an off-by-one error in dropbear introduced in
        # https://github.com/mkj/dropbear/commit/49263b5

Source: GitHub Commit 756cbae

Detection Methods for CVE-2026-62949

Indicators of Compromise

SSH channel open messages (SSH_MSG_CHANNEL_OPEN or SSH_MSG_CHANNEL_OPEN_CONFIRMATION) where the maximum packet size field is set to zero.
Python processes running AsyncSSH that stop responding, exhibit 100% CPU on a single thread, and cease event loop progress after a channel setup.
Stalled connections showing no application-layer traffic despite an established TCP session with an SSH peer.

Detection Strategies

Inventory Python environments and containers for asyncssh package versions below 2.24.0 using pip list or software composition analysis tools.
Deploy network sensors or SSH-aware proxies capable of parsing channel open messages to flag send_pktsize == 0.
Correlate process-level CPU spikes with SSH connection events to identify hangs consistent with the infinite-loop condition.

Monitoring Recommendations

Alert on AsyncSSH-based services that exceed defined liveness or heartbeat thresholds after accepting a new SSH channel.
Log all SSH channel open parameters at the application layer for post-incident review.
Track outbound SSH connections from automation, CI/CD runners, and orchestration agents that use AsyncSSH clients toward untrusted hosts.

How to Mitigate CVE-2026-62949

Immediate Actions Required

Upgrade AsyncSSH to version 2.24.0 or later across all Python services, containers, and virtual environments.
Restrict outbound SSH connections from AsyncSSH clients to trusted, known-good servers until patching is complete.
On AsyncSSH server deployments, restrict channel-open privileges to authenticated principals you trust while remediation is pending.

Patch Information

The fix is available in AsyncSSH 2.24.0, which restores the validation that raises ProtocolError('Invalid maximum packet size') when send_pktsize is zero. See the GitHub Security Advisory GHSA-rw4j-r22c-9gc3, the GitHub Release v2.24.0, and the corrective commit 756cbae.

Workarounds

Wrap AsyncSSH connections in per-connection watchdog timers that cancel tasks exceeding an expected idle window.
Isolate AsyncSSH server workloads into per-connection processes so a single frozen event loop does not block all sessions.
Filter SSH traffic at a bastion or proxy that validates channel-open parameters before forwarding to backend AsyncSSH endpoints.

bash

# Upgrade AsyncSSH to the fixed release
pip install --upgrade 'asyncssh>=2.24.0'

# Verify installed version
python -c "import asyncssh; print(asyncssh.__version__)"