GHSA-G794-3FMP-753H

Vulnerability from github – Published: 2026-05-27 21:35 – Updated: 2026-05-27 21:35
VLAI
Summary
AsyncSSH `AuthorizedKeysFile %u` path traversal allows attacker-selected authorized keys to authenticate a traversal username
Details

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
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "asyncssh"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.22.0"
            },
            {
              "fixed": "2.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.22.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45309"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-27T21:35:06Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nAsyncSSH 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.\n\n## Affected Product\n- Package: asyncssh\n- Ecosystem: pip\n- Affected versions: confirmed on 2.22.0; exact lower bound not finalized\n- Tested version: 2.22.0\n- Audit commit/tag: tag `v2.22.0`, commit `af5a81e669633d83d535163f93b6bf3f957c9238`\n- PyPI sdist SHA256: `c3ce72b01be4f97b40e62844dd384227e5ff5a401a3793007c42f86a5c8eb537`\n\n## Vulnerability Details\n- CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory\n- Component: AsyncSSH server config reload and public-key authentication (`asyncssh/config.py`, `asyncssh/connection.py`, `asyncssh/auth_keys.py`, `asyncssh/misc.py`)\n- 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.\n- Security boundary violated: the configured authorized-keys directory and public-key authentication trust boundary.\n- Direct impact: public-key authentication succeeds using an attacker-selected authorized-keys file outside the intended directory.\n- Chain impact, if any: none claimed; direct authentication impact is primary.\n\n## Attack Preconditions\n- The AsyncSSH server uses a config or equivalent pattern where `AuthorizedKeysFile` contains `%u`, for example `AuthorizedKeysFile authorized_keys/%u`.\n- Public-key authentication is enabled.\n- 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.\n- The application does not separately reject usernames containing `/`, `\\`, or `..` before AsyncSSH uses the username for key-file selection.\n\n## Reproduction\nThe run-scoped evidence contains a safe localhost proof:\n\n1. Start the proof harness saved at \n[harness_app.py](https://github.com/user-attachments/files/27232526/harness_app.py)\n\n2. Run \n[exploit_proof.py](https://github.com/user-attachments/files/27232538/exploit_proof.py)\nthrough \n[run_proof.sh](https://github.com/user-attachments/files/27232545/run_proof.sh)\n\n3. The harness creates `sshd_config` with `AuthorizedKeysFile authorized_keys/%u`, writes the attacker\u0027s public key to a file outside `authorized_keys/`, starts a real AsyncSSH server, and attempts two SSH logins.\n4. Expected result: the normal username `victim` fails, while the traversal username authenticates with the same attacker key.\n\nObserved proof output:\n\n```text\n[CONTROL] username=victim success=False\n[ATTACK] username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub success=True\n[ATTACK] output=AUTH_BYPASS_SUCCESS username=../../../asyncssh-proof-exploit-proof-8b2bd23daeeb.pub\nPASS: traversal username authenticated with attacker-controlled authorized_keys file\n```",
  "id": "GHSA-g794-3fmp-753h",
  "modified": "2026-05-27T21:35:06Z",
  "published": "2026-05-27T21:35:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ronf/asyncssh/security/advisories/GHSA-g794-3fmp-753h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ronf/asyncssh"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AsyncSSH `AuthorizedKeysFile %u` path traversal allows attacker-selected authorized keys to authenticate a traversal username"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.