Vulnerability Database

352,427

Total vulnerabilities in the database

CVE-2026-45309 — asyncssh

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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

  2. Run exploit_proof.py through 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

No technical information available.

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.