A critical vulnerability in OpenSSH’s ProxyCommand feature has been uncovered by security researchers, enabling remote attackers to execute arbitrary code on client systems.
Tracked as CVE-2025-61984, the flaw arises from inadequate filtering of control characters in usernames when expanding the ProxyCommand string.
A proof-of-concept exploit demonstrating this technique across multiple shells has been published, prompting urgent action for organizations relying on SSH proxy configurations.
Vulnerability Details
The vulnerability stems from how ssh(1) it processes the ProxyCommand directive in the user’s ~/.ssh/config file.
When administrators include the %r token to insert the remote username into the proxy command, control characters such as newline are not stripped.
An attacker who can manipulate the username field can inject line breaks that interrupt the intended exec invocation.
When the malformed exec line fails due to a syntax error, execution continues on the next line, where attacker-supplied commands can run with the privileges of the SSH client.
A common attack scenario involves a malicious Git submodule URL.
If a repository’s .gitmodules entry contains a crafted username, and the user’s SSH configuration employs ProxyCommand with %rThe injected control characters trigger the proxy command to execute arbitrary scripts before establishing the SSH connection.
This expansion vulnerability affects OpenSSH client versions up to and including 10.0p1.
Proof-of-Concept Demonstrates Exploit
Researchers have released a proof-of-concept exploit showcasing the attack in Bash, fish, and csh shells. In Bash, injecting $[*] within an exec invocation produces a syntax error that halts the built-in but allows subsequent lines to run.
For example:
bashbash -xc "$(printf 'exec $[*]\necho compromised')"
This command prints “compromised” following the initial parse error. Similar techniques target fish (using exec cat \$p[0]) and csh (using exec $[) to achieve code execution.
Zsh remains unaffected by this specific method, as non-interactive shells abort entirely on parse errors.
The exploit underscores the risk for environments leveraging SSH proxies—particularly cloud gateway solutions that dynamically generate ProxyCommand directives containing %r.
Administrators must assume that any unfiltered username could lead to remote code execution on client machines.
| Affected Products | Impact | Exploit Prerequisites | CVSS 3.1 Score |
|---|---|---|---|
| OpenSSH ≤ 10.0p1 (client) | Remote code execution | User SSH config with ProxyCommand using %r | 8.1 |
The definitive remediation is to upgrade OpenSSH clients to version 10.1p1 or later, where control characters in usernames are explicitly disallowed.
For administrators unable to upgrade immediately, quoting the %r A token in the SSH configuration can mitigate the risk:
textProxyCommand /usr/bin/nc -X connect -x proxy:8080 '%r@%h:%p'
This quoting prevents newline injection by treating the username string literally.
As an additional defense, organizations can enforce stricter handling of Git submodules by disabling unintended SSH transport:
bashgit config --global protocol.ssh.allow user
Limiting URL handlers that pass unfiltered SSH usernames further reduces exposure.
Awareness of this flaw is crucial for any infrastructure using SSH proxies, including Teleport and similar cloud gateway services.
Proper filtering and prompt version updates will protect against this insidious remote code execution vector, securing SSH deployments against emerging exploitation techniques.
Cyber Awareness Month Offer: Upskill With 100+ Premium Cybersecurity Courses From EHA’s Diamond Membership: Join Today
%20(1).webp?resize=1600,900&ssl=1&description=A proof-of-concept exploit demonstrating this technique across multiple shells has been published, prompting urgent action for organizations relying on SSH proxy configurations.){kind=link}