CVE-2026-54591: Arbitrary File Overwrite via Path Traversal in AsyncSSH SCP Implementation

AsyncSSH is a comprehensive, asynchronous Python library that implements the SSHv2 protocol using the Python standard asyncio framework. Due to its modern architectural alignment with asynchronous runtimes, it is extensively used across containerized applications, automated management workflows, and continuous integration engines. One of the core utilities bundled within AsyncSSH is its implementation of the legacy Secure Copy Protocol (SCP), allowing clients to dynamically copy files to and from remote endpoints.\n\nThe attack surface exposed by client-side SCP implementations is structurally distinct from typical server-side exposures. When executing an SCP download operation, the client trusts the remote server to supply the metadata defining the file's properties, including permissions, file sizes, and structural file names. Under malicious circumstances where the remote SSH server is controlled or compromised by an adversary, this trust relationship can be abused to manipulate execution outcomes on the client.\n\nThis security vulnerability, registered under CVE-2026-54591, represents a class of directory traversal weaknesses classified as CWE-22. The implementation fail occurs during client-side receipt of server data in the SCP subsystem. Because the client fails to structurally sanitize the returned name argument, a compromised server can leverage traversal sequences to write to any file path reachable by the executing client process, violating filesystem isolation boundaries.

To understand the mechanics of CVE-2026-54591, it is essential to examine the underlying protocol architecture of Secure Copy (SCP). SCP operates by translating local copy requests into raw remote command executions. When downloading a file, the client requests a file transfer, and the server transmits a structured header line before sending the actual file bytes. This header is typically formatted as a single ASCII string beginning with 'C', followed by file permissions, size, and the proposed filename.\n\nIn vulnerable versions of AsyncSSH, specifically those prior to release 2.23.1, the filename argument is parsed from the ASCII byte string verbatim. The function responsible for decoding these parameters, '_parse_cd_args' in 'asyncssh/scp.py', parses whitespace-separated fields but fails to implement structural checks on the filename field itself. This results in the server-supplied filename, potentially containing relative pathing components, being passed directly down the execution stream.\n\nFollowing parameter extraction, the client system determines where the incoming file must be written. The system resolves this path by executing 'posixpath.join' with the designated local destination directory and the raw, server-supplied filename. Under POSIX environments, executing a path-join with dynamic parent directory sequences (such as '../') resolves the resulting destination relative to the parent paths rather than locking it within the child directory. This behavioral pattern allows the file path to 'climb out' of the target directory structure, targeting arbitrary filesystem locations.

The vulnerability is localized to 'asyncssh/scp.py'. The critical function '_parse_cd_args' is responsible for extracting filename metadata. In vulnerable versions, this function processes the byte arguments using standard string splitting and directly returns the extracted fields. No check is made on the contents of the name bytes, creating an unchecked path ingestion channel.\n\npython\n# Vulnerable implementation in asyncssh/scp.py (version < 2.23.1)\ndef _parse_cd_args(args: bytes) -> Tuple[int, int, bytes]:\n try:\n permissions, size, name = args.split(None, 2)\n return int(permissions, 8), int(size), name\n except ValueError:\n raise _scp_error(SFTPBadMessage, ...)\n\n\nThe remediation introduced in commit 'd730803b8e4e94c20c7580d90f94d1e05f9f58de' targets this specific parsing phase. The patch inserts an explicit validation layer immediately after argument decomposition. It checks for the presence of directory separators or parent directory references, rejecting anomalous inputs prior to any further execution or path manipulation.\n\npython\n# Patched implementation in asyncssh/scp.py (version 2.23.1)\ndef _parse_cd_args(args: bytes) -> Tuple[int, int, bytes]:\n try:\n permissions, size, name = args.split(None, 2)\n\n # Fix introduced in commit d730803b8e4e94c20c7580d90f94d1e05f9f58de\n if b'/' in name or b'\\' in name or name == b'..':\n raise _scp_error(SFTPBadMessage, 'Invalid filename')\n\n return int(permissions, 8), int(size), name\n except ValueError:\n raise _scp_error(SFTPBadMessage,\n 'Invalid SCP control message arguments')\n\n\nmermaid\ngraph LR\n A["Server Packet: 'C0644 1024 ../../.bashrc'"] --> B["_parse_cd_args() Split"]\n B --> C{"Check name for '/', '\\', or '..'"}\n C -- "Pattern Matched" --> D["Raise SFTPBadMessage (Abort)"]\n C -- "No Matches" --> E["Return Validated Args"]\n E --> F["Safe posixpath.join Execution"]\n style D fill:#ffcccc,stroke:#ff0000,stroke-width:2px\n style F fill:#ccffcc,stroke:#00ff00,stroke-width:2px\n\n\nBy matching raw byte sequences prior to any unicode transformation, this patch prevents typical encoding-based bypasses. The explicitly blocked backslash ('\') blocks exploitation attempts targeting Windows-based platforms, while the forward slash ('/') blocks target platforms running POSIX environments. This structural change ensures that the SCP client rejects any packet that attempts to traverse the local filesystem.

Executing the path traversal exploit requires establishing a connection between the target AsyncSSH client and a server controlled by the attacker. Since standard SSH protocols negotiate trust via key exchange, the target client must initiate the connection to a known malicious host or a compromised system that has been configured to serve malicious responses. The attack cannot be launched in an unsolicited manner without client interaction.\n\nOnce the client initiates a download using an 'scp' command, the malicious server responds. Instead of returning the expected safe filenames, the server sends a modified metadata header. For example, if the victim requests a download to '/var/log/app/', the server responds with a header such as 'C0755 4096 ../../../home/user/.bashrc\n'.\n\nThe vulnerable client parses the path relative to '/var/log/app/'. The resulting path resolves to '/home/user/.bashrc', allowing the server to populate this file with attacker-controlled shell scripting commands. When the user subsequently logs in or opens an interactive shell, the system processes '.bashrc', executing the payload with the privileges of the target user account.\n\nThis attack vector is highly effective against automated microservices or data parsing systems running with elevated administrative credentials. In these configurations, an attacker targeting an ingestion engine can overwrite critical python application scripts or system binaries, causing execution hijack or application destabilization.

The CVSS v3.1 score of 8.1 reflects a high-severity rating, highlighting the impact on local integrity and availability. Because the vulnerability is confined to client-side writing, the confidentiality vector is marked as none; the server cannot use this vulnerability to extract raw directory listings or files from the client. However, the integrity impact is high, as the execution of arbitrary file writes on the target system leads directly to security boundary breakdown.\n\nThe potential for escalation to Remote Code Execution (RCE) represents the most severe risk. In Unix-like environments, overwriting shell profile scripts, SSH authorized keys, or cron-jobs grants the attacker consistent persistence and direct shell access. In containers, overwriting application code libraries allows for process hijack and database credential theft.\n\nThe availability impact is also high. An attacker can write over vital system configuration databases or application execution scripts, leading to immediate system denial of service. Since many enterprise systems run automated operations under specialized runtime environments, arbitrary file corruptions can cripple backend cloud infrastructures before detection triggers occur.

Remediation requires upgrading all active installations of 'asyncssh' to version 2.23.1 or higher. This update introduces the validation routines within 'asyncssh/scp.py', ensuring that any path-traversal patterns sent by remote nodes immediately break the execution stream and raise 'SFTPBadMessage' exceptions. Dependency freeze files must be updated to specify 'asyncssh>=2.23.1'.\n\nAdditionally, the maintainer recommends deprecating the use of the legacy SCP protocol altogether. Unlike modern transfer protocols, SCP relies on shell command-line execution frameworks and raw ASCII parsing. Transitioning client architectures to the SFTP (SSH File Transfer Protocol) provides robust transactional validation, native directory sandboxing, and structured packet formats, neutralizing the design flaws inherent to the legacy SCP system.\n\nOrganizations should also enforce local file sandbox restrictions to minimize the blast radius of any potential path-traversal vulnerabilities. Running Python automation scripts under unprivileged user accounts with restricted filesystem access ensures that path-traversal writes cannot impact critical directories like '/etc/' or user-level configuration folders.