PT-2026-59064 · Pypi · Asyncssh

Published 2026-07-13 · Updated 2026-07-13

OSV

CVSS v4.0

6.9

Medium

Base vector

AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P

Summary

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 authorized keys/%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: AsyncSSH server config reload and public-key authentication (asyncssh/config.py, asyncssh/connection.py, asyncssh/auth keys.py, asyncssh/misc.py)
• Root cause: %u in AuthorizedKeysFile is expanded from the remote username without rejecting path separators or .. segments, and the resulting path is opened without constraining it to the intended authorized-keys directory.
• Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary.
• Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory.
• Chain impact, if any: none claimed; direct authentication impact is primary.

Attack Preconditions

• The AsyncSSH server uses a config or equivalent pattern where AuthorizedKeysFile contains %u, for example AuthorizedKeysFile authorized keys/%u.
• Public-key authentication is enabled.
• The attacker can place or reference a readable authorized-keys-format file outside the intended directory, such as a file in a world-writable or application-writable location.
• The application does not separately reject usernames containing /, ``, or .. before AsyncSSH uses the username for key-file selection.

Reproduction

The run-scoped evidence contains a safe localhost proof:

1. Start the proof harness saved at [harness app.py](https://github.com/user-attachments/files/27232526/harness app.py)
2. Run [exploit proof.py](https://github.com/user-attachments/files/27232538/exploit proof.py) through [run proof.sh](https://github.com/user-attachments/files/27232545/run proof.sh)
3. The harness creates sshd config with AuthorizedKeysFile authorized keys/%u, writes the attacker's public key to a file outside authorized keys/, starts a real AsyncSSH server, and attempts two SSH logins.
4. Expected result: the normal username victim fails, while the traversal username authenticates with the same attacker key.

Observed proof output:

[CONTROL] username=victim success=False
[ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True
[ATTACK] output=AUTH BYPASS SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub
PASS: traversal username authenticated with attacker-controlled authorized keys file

Fix

Related Identifiers

PYSEC-2026-2384

Affected Products

Asyncssh

References · 6

• https://nvd.nist.gov/vuln/detail/CVE-2026-45309 · Security Note
• https://osv.dev/vulnerability/PYSEC-2026-2384 · Vendor Advisory
• https://github.com/ronf/asyncssh · Note
• https://github.com/ronf/asyncssh/security/advisories/GHSA-g794-3fmp-753h · Note
• https://github.com/advisories/GHSA-g794-3fmp-753h · Note
• https://pypi.org/project/asyncssh · Note