There are 3 open security issues in trixie.
3 issues left for the package maintainer to handle:
- CVE-2026-45309:
(needs triaging)
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.23.0, AsyncSSH expands the OpenSSH-compatible AuthorizedKeysFile %u token in asyncssh/config.py, asyncssh/connection.py, asyncssh/auth_keys.py, and asyncssh/misc.py with the raw SSH username during pre-authentication server config reload, allowing a server configured with AuthorizedKeysFile authorized_keys/%u to read an authorized-keys file outside the intended directory when the SSH username contains /, \, or .. path traversal segments and authenticate with an attacker-selected key file. This issue is fixed in version 2.23.0.
- CVE-2026-54591:
(needs triaging)
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.23.1, a malicious SSH server can write arbitrary files on the asyncssh SCP client's filesystem by sending filenames containing ../ traversal sequences because _parse_cd_args in scp.py returns server-provided names verbatim and _recv_files joins them to the destination path without enforcing the target directory boundary. This issue is fixed in version 2.23.1.
- CVE-2026-62949:
(needs triaging)
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.
You can find information about how to handle these issues in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/p/python-asyncssh.png){kind=link}