| | | |---|---| | 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:

C0644 100 ../pwned.txt\n (simple traversal)

D0755 0 ..\n (traverse up, repeat as needed) C0644 47 .bashrc\n (write payload) E\n

Step 3 - parsecdargs (scp.py:134-142) returns the filename verbatim:

python def parsecdargs(args: bytes) -> Tuple[int, int, bytes]: permissions, size, name = args.split(None, 2) return int(permissions, 8), int(size), name # no sanitization

The returned name is not passed through basename() and is not checked for .. or / components.

Step 4 - recvfiles (scp.py:706-713) joins the unsanitized name:

python newdstpath = posixpath.join(dstpath, name)

With dstpath=b'/home/user/downloads/subdir' and name=b'../pwned.txt', this resolves to /home/user/downloads/pwned.txt, outside the target.

Step 5 - File write: recvfile opens the traversed path via self.fs.open(dstpath, 'wb') and writes attacker-controlled content. The resolved path is not checked against the target directory boundary.

Step 6 - RCE chains:

| Target | Execution trigger | Reliability | |---|---|---| | ~/.bashrc | Next terminal open | High | | ~/.profile | Next login | High | | ~/.ssh/rc | Next SSH connection (requires sshd) | High | | ~/.ssh/authorizedkeys | Attacker logs in with command= | Medium |

---

Reproduction:

Link to reproduction script: pathtraversalpoc.zip

bash docker build -t asyncssh-scp-traversal -f Dockerfile . docker run --rm asyncssh-scp-traversal

The attached pocscptraversal.py starts a malicious SSH server in-process using asyncssh's own API, then downloads from it via asyncssh.scp().

Expected Output:

<img width="1400" height="815" alt="image" src="https://github.com/user-attachments/assets/496745e4-d11d-4ed8-bddd-d15dd13d1751" />

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, processchannelopen and processchannelopenconfirmation in asyncssh/connection.py accept a peer-supplied sendpktsize value of zero. When channel data reaches SSHChannel.flushsendbuf 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 SSHMSGCHANNELOPENCONFIRMATION before the first channel write, while an authenticated client can trigger the server path through SSHMSGCHANNELOPEN and freeze every current and future connection handled by the process. This vulnerability is fixed in 2.24.0.