Affected: Homebrew: dvc

## Summary

A malicious SSH server can wedge an AsyncSSH **client**, and an authenticated client can wedge an AsyncSSH **server**, by sending a channel `maximum packet size` of `0` in `SSH_MSG_CHANNEL_OPEN_CONFIRMATION` (server→client) or `SSH_MSG_CHANNEL_OPEN` (client→server). AsyncSSH stores the peer-supplied value verbatim with no lower-bound check; the first time channel data is written, `SSHChannel._flush_send_buf` enters a **synchronous infinite loop** that cannot be interrupted by `asyncio.wait_for` or any timeout. The loop body has no `await`, so it blocks the entire asyncio event loop — for a server, one malicious authenticated channel freezes **all** current and future connections.

RFC 4254 §5.1 leaves receiver behavior for a peer-reported "maximum packet size = 0" undefined, so the value must be rejected rather than stored.

## Root cause

`asyncssh/channel.py`:

```python # process_open (server side) -- line 465 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# process_open_confirmation (client) -- line 528 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# _flush_send_buf -- lines 305-320 while self._send_buf and self._send_window: pktsize = min(self._send_window, self._send_pktsize) # 0 when peer sends 0 buf, datatype = self._send_buf[0] if len(buf) > pktsize: # True for any buffered data data = buf[:pktsize] # empty (b'') del buf[:pktsize] # no-…

Affected: CleanStart: airflow-3

CVE-2026-62949 affects multiple packages. AsyncSSH is a Python package which provides an asynchronous client and server implementation of the SSHv2 protocol on top of the Python asyncio framework. See references for individual vulnerability details.

AsyncSSH is a Python package which provides an asynchronous client and server implementation of the SSHv2 protocol on top of the Python asyncio framework. Prior to 2.24.0, _process_channel_open and _process_channel_open_confirmation in asyncssh/connection.py accept a peer-supplied send_pktsize value of zero. When channel data reaches SSHChannel._flush_send_buf in asyncssh/channel.py, the zero value causes each loop iteration to slice and remove zero bytes without reducing the send window, leaving the synchronous loop permanently true with no await point. A malicious SSH server can trigger the client path through SSH_MSG_CHANNEL_OPEN_CONFIRMATION before the first channel write, while an authenticated client can trigger the server path through SSH_MSG_CHANNEL_OPEN and freeze every current and future connection handled by the process. This vulnerability is fixed in 2.24.0.

Affected: PyPI: asyncssh

## Summary

A malicious SSH server can wedge an AsyncSSH **client**, and an authenticated client can wedge an AsyncSSH **server**, by sending a channel `maximum packet size` of `0` in `SSH_MSG_CHANNEL_OPEN_CONFIRMATION` (server→client) or `SSH_MSG_CHANNEL_OPEN` (client→server). AsyncSSH stores the peer-supplied value verbatim with no lower-bound check; the first time channel data is written, `SSHChannel._flush_send_buf` enters a **synchronous infinite loop** that cannot be interrupted by `asyncio.wait_for` or any timeout. The loop body has no `await`, so it blocks the entire asyncio event loop — for a server, one malicious authenticated channel freezes **all** current and future connections.

RFC 4254 §5.1 leaves receiver behavior for a peer-reported "maximum packet size = 0" undefined, so the value must be rejected rather than stored.

## Root cause

`asyncssh/channel.py`:

```python # process_open (server side) -- line 465 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# process_open_confirmation (client) -- line 528 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# _flush_send_buf -- lines 305-320 while self._send_buf and self._send_window: pktsize = min(self._send_window, self._send_pktsize) # 0 when peer sends 0 buf, datatype = self._send_buf[0] if len(buf) > pktsize: # True for any buffered data data = buf[:pktsize] # empty (b'') del buf[:pktsize] # no-…

python313-asyncssh-2.24.0-1.1 on GA media

Affected: PyPI: asyncssh

## Summary

A malicious SSH server can wedge an AsyncSSH **client**, and an authenticated client can wedge an AsyncSSH **server**, by sending a channel `maximum packet size` of `0` in `SSH_MSG_CHANNEL_OPEN_CONFIRMATION` (server→client) or `SSH_MSG_CHANNEL_OPEN` (client→server). AsyncSSH stores the peer-supplied value verbatim with no lower-bound check; the first time channel data is written, `SSHChannel._flush_send_buf` enters a **synchronous infinite loop** that cannot be interrupted by `asyncio.wait_for` or any timeout. The loop body has no `await`, so it blocks the entire asyncio event loop — for a server, one malicious authenticated channel freezes **all** current and future connections.

RFC 4254 §5.1 leaves receiver behavior for a peer-reported "maximum packet size = 0" undefined, so the value must be rejected rather than stored.

## Root cause

`asyncssh/channel.py`:

```python # process_open (server side) -- line 465 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# process_open_confirmation (client) -- line 528 self._send_pktsize = send_pktsize # peer value, no >= 1 check

# _flush_send_buf -- lines 305-320 while self._send_buf and self._send_window: pktsize = min(self._send_window, self._send_pktsize) # 0 when peer sends 0 buf, datatype = self._send_buf[0] if len(buf) > pktsize: # True for any buffered data data = buf[:pktsize] # empty (b'') del buf[:pktsize] # no-…

Affected: Ubuntu:16.04:LTS: python-asyncssh, Ubuntu:Pro:18.04:LTS: python-asyncssh, Ubuntu:20.04:LTS: python-asyncssh, Ubuntu:Pro:22.04:LTS: python-asyncssh, Ubuntu:Pro:24.04:LTS: python-asyncssh, Ubuntu:26.04:LTS: python-asyncssh

AsyncSSH is a Python package which provides an asynchronous client and server implementation of the SSHv2 protocol on top of the Python asyncio framework. Prior to 2.24.0, _process_channel_open and _process_channel_open_confirmation in asyncssh/connection.py accept a peer-supplied send_pktsize value of zero. When channel data reaches SSHChannel._flush_send_buf in asyncssh/channel.py, the zero value causes each loop iteration to slice and remove zero bytes without reducing the send window, leaving the synchronous loop permanently true with no await point. A malicious SSH server can trigger the client path through SSH_MSG_CHANNEL_OPEN_CONFIRMATION before the first channel write, while an authenticated client can trigger the server path through SSH_MSG_CHANNEL_OPEN and freeze every current and future connection handled by the process. This vulnerability is fixed in 2.24.0.