CVE-2026-35386

What it actually does

OpenSSH before 10.3 can allow command injection when an untrusted username is placed into an SSH command line and then expanded through non-default ssh_config percent-token behavior. The issue is local and high-complexity: an attacker generally needs the ability to influence the username value used by a local SSH invocation, and the client configuration must use a vulnerable non-default '%' expansion pattern. If those conditions are met, shell metacharacters embedded in the username can alter the intended command line and execute unintended commands with the privileges of the process or user launching ssh.

Why it matters to the business

The practical risk is limited to systems, automation, scripts, or tooling that build SSH commands from untrusted usernames while using affected OpenSSH client versions and non-standard ssh_config percent expansions. In affected workflows, an attacker could tamper with files, read limited data, or run unintended commands under the invoking user's privileges. The CVSS and EPSS values are low, there is no known KEV listing, no known ransomware association, and no public exploit maturity reported, so this should be remediated through normal patch and configuration hygiene rather than emergency response unless the organization has automation that accepts externally supplied SSH usernames.

How an attack unfolds

An attacker first identifies an application, script, wrapper, CI/CD job, orchestration tool, or administrative workflow that constructs an ssh command using a username value the attacker can influence. The attacker then supplies a crafted username containing shell metacharacters such as command separators, command substitution, pipes, or redirection characters. If the local OpenSSH client is older than 10.3 and its ssh_config uses a non-default '%' expansion in a way that places the username into a shell-interpreted command line, the crafted username may break out of the intended argument context. The resulting command line can execute attacker-supplied commands as the local user or service account that launched ssh. Successful exploitation is therefore highly dependent on local configuration and unsafe command construction, not simply network exposure of an SSH server.

How to fix it

Upgrade OpenSSH to version 10.3 or later wherever the OpenSSH client is installed, prioritizing systems that run SSH automation, bastion tooling, deployment scripts, CI/CD jobs, orchestration platforms, or account-provisioning workflows. If a vendor package has not yet provided OpenSSH 10.3, apply the vendor's security update when available. As a mitigation, review ssh_config and included configuration files for non-default '%' expansion usage, especially in directives that can influence command execution or proxy behavior. Remove unnecessary percent-token expansion, avoid shell interpretation where possible, and ensure all usernames used in SSH invocations come from trusted sources or are strictly validated against a safe character allowlist such as alphanumeric characters plus a small set of explicitly required separators. Avoid building SSH commands through shell string concatenation; use argument arrays or equivalent safe process-execution APIs.

How to confirm the fix worked

Confirm installed OpenSSH client versions with commands such as 'ssh -V' and verify they report OpenSSH_10.3 or later, or a vendor-backported package that explicitly includes the fix. Review global and user SSH client configuration files, commonly /etc/ssh/ssh_config, /etc/ssh/ssh_config.d/*.conf, ~/.ssh/config, and included files, for non-default '%' expansion usage. Validate that automation and wrappers do not concatenate untrusted usernames into shell command strings. Test representative workflows with benign metacharacter-containing usernames in a controlled environment and confirm they are rejected or safely treated as literal input rather than executed. Package and configuration management should be used to continuously verify that affected OpenSSH versions and risky ssh_config patterns do not reappear.

Typical attack path

1. Find a script, tool, service, or automation workflow that invokes the OpenSSH client and accepts or derives a username from untrusted input.
2. Provide a username containing shell metacharacters or command-substitution syntax.
3. Rely on an affected OpenSSH version before 10.3 and a non-default ssh_config '%' expansion that causes the username to be inserted into a command line context.
4. Trigger the SSH invocation through the vulnerable workflow.
5. Execute unintended local commands with the privileges of the user or service account running the SSH client.
6. Use the resulting access to read accessible files, modify data, stage additional tooling, or pivot within the limits of that account's permissions.

How to detect it

Detection should focus on evidence that local SSH client invocations included suspicious username values and that unexpected child processes were launched from ssh-related automation. Review shell history, process execution telemetry, EDR events, auditd logs, syslog, CI/CD job logs, deployment logs, and application logs for ssh commands where the username or destination string contains shell metacharacters such as ';', '|', '&', '`', '$(', '>', '<', or newline escapes. On Linux, process lineage is especially useful: look for ssh launched by automation followed by unexpected shell, curl, wget, Python, Perl, nc, bash, sh, or file-modification commands under the same user context. Review /etc/ssh/ssh_config, /etc/ssh/ssh_config.d/*.conf, ~/.ssh/config, and included files for risky percent-token expansion patterns, then correlate the affected users and hosts with suspicious command execution during the relevant time window. Since no public exploit maturity or named threat actor activity is reported, prioritize hunting around systems where untrusted input can influence SSH usernames rather than broad internet-facing SSH server logs.

• OpenSSH_10.0
• OpenSSH_10.1
• OpenSSH_10.2
• /etc/ssh/ssh_config
• /etc/ssh/ssh_config.d/
• ~/.ssh/config
• ssh -l *;*
• ssh -l *|*
• ssh -l *&*
• ssh -l *`*
• ssh -l *$(*
• ssh *@*;*
• ssh *@*|*
• ssh *@*&*
• ssh *@*`*
• ssh *@*$(*
• ProxyCommand
• LocalCommand
• PermitLocalCommand
• Match exec
• Include

What your security team should do

• Inventory systems running OpenSSH clients before 10.3, especially automation hosts, CI/CD runners, deployment servers, bastions, jump hosts, and administrative workstations.
• Patch OpenSSH clients to 10.3 or later, or apply vendor-provided fixed packages when available.
• Search ssh_config files for non-default '%' expansion patterns and remove or redesign risky directives that may place usernames into shell-interpreted contexts.
• Review scripts and applications that build ssh command lines from user-controlled or externally supplied usernames; replace shell concatenation with safe process invocation and strict input validation.
• Prioritize code review for workflows where usernames originate from web forms, APIs, source repositories, ticketing systems, identity data, or other semi-trusted sources.
• Add logging or alerting for SSH invocations containing shell metacharacters in username-like fields.
• Because the issue is not in KEV, has low EPSS, and has no reported exploit maturity, handle through standard vulnerability management unless local exposure analysis finds untrusted username-to-ssh automation paths.