Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 SSHMSGCHANNELOPENCONFIRMATION (server→client) or SSHMSGCHANNELOPEN (client→server). AsyncSSH stores the peer-supplied value verbatim with no lower-bound check; the first time channel data is written, SSHChannel.flushsendbuf enters a synchronous infinite loop that cannot be interrupted by asyncio.waitfor 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: With sendpktsize == 0, pktsize is 0, so buf[:0] is empty, del buf[:0] is a no-op, and sendwindow is never decremented — the while condition is permanently true, and…
Recommended action: Upgrade to 2.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
| | | |---|---| | Product | asyncssh (all versions through 2.23.0) | | Related | CVE-2019-6111 (same class in OpenSSH) | | Fix | AsyncSSH 2.23.1 | A malicious SSH server can write arbitrary files on the asyncssh SCP client's filesystem by sending filenames containing ../ traversal sequences. The SCP receive path does not currently sanitize server-provided filenames. By chaining directory traversals via the D (directory) action, an attacker can escape any target directory and overwrite ~/.bashrc, ~/.ssh/rc, or ~/.ssh/authorizedkeys, achieving code execution. This is the same vulnerability class as CVE-2019-6111. The mitigation applied in OpenSSH does not appear to have been adopted in asyncssh. --- Steps to exploit: Step 1 - Normal usage: Application calls await asyncssh.scp((conn, 'file'), '/home/user/downloads/'). This is the standard, documented API. Step 2 - SCP protocol: asyncssh opens an SSH exec channel, runs scp -f file. The server controls the filename field: Step 3 -…
Recommended action: Upgrade to 2.23.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Incomplete fix for CVE-2026-45309 (GHSA-g794-3fmp-753h). The 2.23.0 guard that sanitises the SSH username before %u substitution in AuthorizedKeysFile blocks /, \ and .., but does not block a leading ~ (or ${ENV}), both of which are re-introduced by later expansion and reach the file open — defeating the guard. Affected: asyncssh 2.23.0 and current develop (commit a60f863, HEAD on 2026-05-29). Summary The fix for CVE-2026-45309 added a guard in SSHServerConfig.settokens (asyncssh/config.py:715-716) that rejects an SSH username containing /, \, or equal to .., before it is substituted for the %u token in AuthorizedKeysFile: if self.user == '..' or '/' in self.user or '\\' in self.user: raise IllegalUserName('Unsafe username substitution') However, the %u-substituted value is subsequently passed through environment-variable expansion (expandval, config.py:145-149 — token expansion then env expansion) and, at file-open time, through expanduser() (readauthorizedkeys → readfile →…
Recommended action: Upgrade to 2.23.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AsyncSSH 2.22.0 expands the OpenSSH-compatible AuthorizedKeysFile %u token with the raw SSH username during pre-authentication server config reload. A server configured with a documented per-user key pattern such as AuthorizedKeysFile authorizedkeys/%u can be made to read an authorized-keys file outside the intended directory when the SSH username contains path traversal segments. If the attacker can place or reference a readable authorized-keys-format file containing their public key, the attacker can authenticate over SSH as the traversal username. Affected Product - Package: asyncssh - Ecosystem: pip - Affected versions: confirmed on 2.22.0; exact lower bound not finalized - Tested version: 2.22.0 - Audit commit/tag: tag v2.22.0, commit af5a81e669633d83d535163f93b6bf3f957c9238 - PyPI sdist SHA256: c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537 Vulnerability Details - CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory - Component:…
Recommended action: Upgrade to 2.23.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
AsyncSSH v2.14.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security. Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Support for strict key exchange has been added to AsyncSSH in the patched version. Warning: To take effect, both the client and server must support this countermeasure. As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. Details The SSH specifications of ChaCha20-Poly1305…
Recommended action: Upgrade to 2.14.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the remote end of an SSH client session via packet injection/removal and shell emulation. Details The rogue session attack targets any SSH client connecting to an AsyncSSH server, on which the attacker must have a shell account. The goal of the attack is to log the client into the attacker's account without the client being able to detect this. At that point, due to how SSH sessions interact with shell environments, the attacker has complete control over the remote end of the SSH session. The attacker receives all keyboard input by the user, completely controls the terminal output of the user's session, can send and receive data to/from forwarded network ports, and is able to create signatures with a forwarded SSH Agent, if any. The result is a complete break of the confidentiality and integrity of the secure channel, providing a strong vector for a targeted phishing campaign against the user. For example,…
Recommended action: Upgrade to 2.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue in AsyncSSH v2.14.0 and earlier allows attackers to control the extension info message (RFC 8308) via a man-in-the-middle attack. Details The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it. A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2). PoC <details <summaryAsyncSSH Client 2.14.0 (simpleclient.py example) connecting to AsyncSSH Server 2.14.0…
Recommended action: Upgrade to 2.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The SSH server implementation of AsyncSSH before 1.12.1 does not properly check whether authentication is completed before processing other requests. A customized SSH client can simply skip the authentication step.
Recommended action: Upgrade to 1.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.