Summary
AsyncSSH expands an AuthorizedKeysFile %u token using the raw SSH username, allowing path traversal sequences to escape the intended authorized-keys directory.
When a server is configured with user-expanded authorized-keys paths, an attacker-controlled username containing traversal characters may cause the server to read and trust an attacker-selected key file.
AsyncSSH expands an AuthorizedKeysFile %u token using the raw SSH username, allowing path traversal sequences to escape the intended authorized-keys directory.
When a server is configured with user-expanded authorized-keys paths, an attacker-controlled username containing traversal characters may cause the server to read and trust an attacker-selected key file.
Affected context
This vulnerability occurs in AsyncSSH server deployments that:
- Use OpenSSH-compatible AuthorizedKeysFile directives
- Include the %u token for per-user authorized key paths (e.g.,
authorized_keys/%u) - Accept or derive SSH usernames that are not sanitized for path traversal characters
Under these conditions, the server's key lookup logic can be directed outside the intended authorized-keys directory.
This vulnerability occurs in AsyncSSH server deployments that:
- Use OpenSSH-compatible AuthorizedKeysFile directives
- Include the %u token for per-user authorized key paths (e.g.,
authorized_keys/%u) - Accept or derive SSH usernames that are not sanitized for path traversal characters
Under these conditions, the server's key lookup logic can be directed outside the intended authorized-keys directory.
Exploit preconditions
- Attack surface: SSH server authentication logic using AsyncSSH
- Required access: Ability to initiate SSH connections and supply a crafted SSH username
- Trigger point: Expansion of the AuthorizedKeysFile %u token during pre-authentication config reload and key file resolution
- Why exploitation is possible: The username is interpolated into file paths without normalization or validation, enabling traversal via
/,\, or..segments
- Attack surface: SSH server authentication logic using AsyncSSH
- Required access: Ability to initiate SSH connections and supply a crafted SSH username
- Trigger point: Expansion of the AuthorizedKeysFile %u token during pre-authentication config reload and key file resolution
- Why exploitation is possible: The username is interpolated into file paths without normalization or validation, enabling traversal via
/,\, or..segments
Why this happens
The underlying bug stems from unsafe use of user-controlled data in filesystem paths.
AsyncSSH expands the %u placeholder in AuthorizedKeysFile using the raw SSH username and then directly uses that value to construct the path to the authorized-keys file.
Without proper sanitization, normalization, or restriction to a fixed directory root, this behavior matches CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as attackers can introduce traversal sequences to access files outside the expected location and influence authentication decisions.
The underlying bug stems from unsafe use of user-controlled data in filesystem paths.
AsyncSSH expands the %u placeholder in AuthorizedKeysFile using the raw SSH username and then directly uses that value to construct the path to the authorized-keys file.
Without proper sanitization, normalization, or restriction to a fixed directory root, this behavior matches CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as attackers can introduce traversal sequences to access files outside the expected location and influence authentication decisions.
Potential impact
- An attacker could cause the server to load an authorized-keys file from an unintended directory.
- Authentication may succeed using public keys not actually associated with the target account.
- SSH access could be granted based on attacker-selected key material, effectively bypassing normal account authorization.
- Misuse of arbitrary filesystem locations may expose sensitive configuration or key files used in authentication decisions.
- An attacker could cause the server to load an authorized-keys file from an unintended directory.
- Authentication may succeed using public keys not actually associated with the target account.
- SSH access could be granted based on attacker-selected key material, effectively bypassing normal account authorization.
- Misuse of arbitrary filesystem locations may expose sensitive configuration or key files used in authentication decisions.
General mitigation guidance
Mitigation generally focuses on constraining how user input influences filesystem paths and enforcing strict directory boundaries.
Recommended defensive patterns include:
- Normalizing and validating usernames before using them in path expansion, rejecting any containing
/,\, or... - Confining AuthorizedKeysFile lookups to a fixed base directory and enforcing that resolved paths remain within that directory.
- Avoiding direct interpolation of user-controlled values into file paths; instead, map usernames to safe, canonical identifiers.
- Applying least-privilege to the SSH service's filesystem access so that even misdirected paths cannot reach sensitive files.
Mitigation generally focuses on constraining how user input influences filesystem paths and enforcing strict directory boundaries.
Recommended defensive patterns include:
- Normalizing and validating usernames before using them in path expansion, rejecting any containing
/,\, or... - Confining AuthorizedKeysFile lookups to a fixed base directory and enforcing that resolved paths remain within that directory.
- Avoiding direct interpolation of user-controlled values into file paths; instead, map usernames to safe, canonical identifiers.
- Applying least-privilege to the SSH service's filesystem access so that even misdirected paths cannot reach sensitive files.
How teams detect issues like this
Detection typically involves examining both configuration and code paths where usernames influence filesystem access.
Approaches include:
- Static analysis rules that flag path construction using raw usernames or other user-controlled identifiers.
- Code review practices that look for AuthorizedKeysFile or similar directives using expansion tokens without validation.
- Configuration audits to identify patterns like
authorized_keys/%uand confirm associated sanitation logic. - File access monitoring around the authorized-keys directory to detect unexpected lookups in sibling or parent directories.
Detection typically involves examining both configuration and code paths where usernames influence filesystem access.
Approaches include:
- Static analysis rules that flag path construction using raw usernames or other user-controlled identifiers.
- Code review practices that look for AuthorizedKeysFile or similar directives using expansion tokens without validation.
- Configuration audits to identify patterns like
authorized_keys/%uand confirm associated sanitation logic. - File access monitoring around the authorized-keys directory to detect unexpected lookups in sibling or parent directories.
